Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

To be a kind of moral Unix, he touched the hem of Nature's shift. -- Shelley


computers / comp.os.vms / latest

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 3 Minutes ago by: Arne_Vajhøj

It is really two different tools intended for different purposes. My claim is that: - it would be silly to try and write an OS kernel or device drivers in Basic (any existing Basic) - it would be silly to write a business money app

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 7 Minutes ago by: Arne_Vajhøj

Probably nothing. But no such Basic compiler exist. Which makes it a very theoretical discussion. Most likely anything could be written in any language in theory. Some things may be a bit extra work, but ... Decisions about what lang

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 12 Minutes ago by: Arne_Vajhøj

Ada and the rest of that "language family" including Pascal and Modula-2. That applies for Ada type. Not for Ada subtype and Pascal. But yes - it is a really really strong feature in Ada. True strict type check. It can also be a prob

Re: How to send multiple commands to a DCL subprocess? (thread)

comp.os.vms

Posted: 23 Minutes ago by: Arne_Vajhøj

I don't have an explanation for your specific problem. But my experience is that LIB$SPANW is problematic for general DCL commands - it is much better to create a pseudo terminal (ptd$ functions). Arne

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 26 Minutes ago by: chris

If I can answer here, nothing in extremis, but is about ease of use. Its years since I did any basic, but the only way to access memory or io devices at the time was via peeks and pokes, which makes it less than optimum for the sort for l

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 39 Minutes ago by: gah4

(snip) Looking at: https://en.wikipedia.org/wiki/IBM_1401#Character_and_op_codes it seems both are right. Arithmetic and addressing is BCD. Characters and opcodes use all six bits (BA8421) and could be represented in octal.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Hour 2 Minutes ago by: Bill Gunshannon

Not octal, just machine code. I didn't get octal till the PDP-11 and I do like it. I can do octal math in my head as well as I can do decimal math. bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Hour 24 Minutes ago by: chris

Having spent several years programming 6502 for embedded systems, I can confirm that all the registers on the 6502 were eight bit. Hence the reason for the indirect addressing modes, which allowed 16 bit pointers in page zero to access th

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 1 Hour 36 Minutes ago by: Rich Alderson

The 1401 was my first computer, and I don't recall using octal. It was a BCD computer, and we learned the character codes for that kind of hacking...

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 3 Hours 13 Minutes ago by: Dave Froble

Ok, gauntlet thrown down, and picked up. Leaving out the specifics of the implementation of DEC Basic, which include not thread safe, and other things, I would like to know just what C can do that Basic can not do. I will admit that s

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 3 Hours 18 Minutes ago by: gah4

(snip) The 6502 was designed for embedded processing, and some people who do that seem to like it more than others. The 8 bit stack pointer and 8 bit index registers, compared to the 16 bit versions in the 6800 can be less convenient f

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 3 Hours 41 Minutes ago by: Bob Eager

I have lost count of the number of assembly languages I have used. But they included some DEC ones: PAL-8, Macro-11, Macro-32, Macro-10...as well as 6502, which is probably the lowest level (ah, but there was 8080...). And some obscu

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Hours 57 Minutes ago by: Bill Gunshannon

I never liked 6502. I've worked with at least 10 different architectures and the only one I liked less than the 6502 was the Pr1me. Much of it's quirks were fixed when native mode Unix was developed because it included modification to t

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 5 Hours 37 Minutes ago by: chris

What made the 6502 a bit special was the variety of addressing modes, which included pre and post indexed addressing. Very useful for traversing lists and trees. That and instruction mnemonics borrowed from pdp11, even if the architecture

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 5 Hours 44 Minutes ago by: chris

' I think the pythonesque retort to that was "You were lucky, we used to have to lick out't pond" :-). Have in fact keyed in bootstrap into an 11/05, which worked. That and the fact that the 11/05 register set was mapped into memory addr

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 6 Hours 14 Minutes ago by: gah4

(snip) There are some interesting things that can be done with dd. if you use bs=(large number) then dd reads blocks up to and including (large number) bytes, and then writes them out again. You can make a copy of a VB or VBS tape,

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 6 Hours 26 Minutes ago by: Simon Clubley

It's been a very long time since I used either, but I was left with the memory that I preferred Z80 over 6502, although the details have been lost to time... Simon.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 6 Hours 28 Minutes ago by: Simon Clubley

Lucky you! I had to be happy with using a really small magnet to program the core memory... Beat that! Simon. PS: On a more serious note, the only time I have seen core memory is in a museum or in pictures. The thing that strikes me ab

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 6 Hours 36 Minutes ago by: Simon Clubley

Some C programmers say that there's nothing wrong with C and that it's your fault if you are not careful enough when writing C code. I am not one of them because, for me, I continue to use C because it's the most viable language for some

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 6 Hours 39 Minutes ago by: Johnny Billquist

Why do you think it is any different there? Try dd on a tape, giving bs24 for a tar tape, and observe how your copy is missing 90% of the content. There might be controllers/hardware that allow larger blocks, but it's quite common to

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 6 Hours 58 Minutes ago by: Johnny Billquist

Octal? You had octal? You lucky bastards. We had to be content with binary. (Go ahead. Make my day. Continue this thread... :-D ) Johnny

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 7 Hours 1 Minute ago by: Johnny Billquist

Pretty much mandatory in soaring. But that is a very specific subset of aircraft... Johnny

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 7 Hours 4 Minutes ago by: Johnny Billquist

In a sense, this is something Ada really got right. You don't declare how many bits, signedness and so on you want. You declare your integers with the range you need them to have, and let the language/compiler figure out how to represe

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 7 Hours 7 Minutes ago by: Johnny Billquist

Well. There is no way to tell if a 36 bit integer would actually be acceptable if you try to use something you think are 32 bits, so it's still the safe option to fail such code. :-D Johnny

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 8 Hours 4 Minutes ago by: Bill Gunshannon

I'm sure many of us here have done it. Whether we enjoyed it or not is another question. :-) bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 10 Hours 1 Minute ago by: Single Stage to Orbi

I'm sure there'll be a chap along in a minute to regale us with tales of how he used to key machine code into the computer using toggles ...

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 10 Hours 20 Minutes ago by: chris

I preferred 6502 asm and macro 11 to anything else I had access to at time. The rest of you all were lucky :-)... Chris

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 10 Hours 25 Minutes ago by: Bill Gunshannon

Learned to do that on the IBM 1401 when I learned Autocoder. Efficiency was important in those days and the output from the Autocoder translator had way too much fluff. Used to be fun to Compile a utility program written in Autocoder, lo

Re: How to send multiple commands to a DCL subprocess? (thread)

comp.os.vms

Posted: 10 Hours 41 Minutes ago by: Craig A. Berry

Try sending the commands in separate writes with an fsync() in the writer on the pipe's file descriptor after each command. On the CRTL's mailbox-based pipes, that will give you a new record in the mailbox regardless of whatever stream

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 11 Hours 7 Minutes ago by: Dan Cross

Anything other than machine code in octal is for pikers. - Dan C.

Re: How to send multiple commands to a DCL subprocess? (thread)

comp.os.vms

Posted: 12 Hours 23 Minutes ago by: VAXman-

ROTFLMFAO! $ CRLF[0,16]=%x0A0D $ COMMAND:="SHOW DEFAULT" $ SPAWN 'COMMAND %DCL-S-SPAWNED, process SYSTEM_14176 spawned %DCL-S-ATTACHED, terminal now attached to process SYSTEM_14176 SYS$SYSROOT:[SYSMGR] = SYS$SYSROOT:[SYSMGR] =

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 13 Hours 50 Minutes ago by: Single Stage to Orbi

I preferred 6502 assembler to BASIC on the Beeb.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 16 Hours ago by: Ian Miller

I preferred BCPL to BASIC on the BBC Computer.

How to send multiple commands to a DCL subprocess?

comp.os.vms

Posted: 21 Hours 13 Minutes ago by: Jake Hamby

I've been working on updating the open source Regina Rexx interpreter to revive the native support it has for VMS, and I have a question about how best to create a mailbox/pipe for sending multiple DCL commands to a spawned subprocess via

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day ago by: Bob Eager

I did a BCPL compiler to generate Macro-11. Well, binary instructions.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 1 Hour ago by: Bill Gunshannon

BCPL is for wimps. Stick with Macro-11. bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 3 Hours ago by: Bob Eager

C is for wimps. Try BCPL.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 4 Hours ago by: Dave Froble

What attitude is that? Think I'll stick to Basic. Does what I need. Has strings built in.

Re: DCL vulnerability, was: Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 1 Day 5 Hours ago by: Stephen Hoffman

Arbitrary code executing in supervisor mode in the context of DCL can gain full system access.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 1 Day 6 Hours ago by: Simon Clubley

With that attitude David, you should switch to using C... :-) Simon.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 7 Hours ago by: Dave Froble

That hat you pull all this info out of. Does it give winning lottery numbers?

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 7 Hours ago by: Dave Froble

Yes, I did. You're not the only dinosaur around. Damn teletype machines, almost needed a hammer to depress the keys.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 7 Hours ago by: Dave Froble

Cirrus, and others ..

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 7 Hours ago by: Dave Froble

If people would not jump out of perfectly airworthy aircraft, they would not be required. That would be the reserve parachute, for when the primary doesn't open. When a fully loaded tri-axle truck runs over a car, then no car is safe

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 7 Hours ago by: Bill Gunshannon

I have flown in a lot of stuff from Piper Cubs to C5A Galaxy. I have never seen a parachute in a non-military aircraft. (with the exception of skydiving rides!) bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 7 Hours ago by: Chris Townley

Many light aircraft do!

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 7 Hours ago by: Bill Gunshannon

You never did much typing at 110 (or 60) baud, did you? bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 1 Day 8 Hours ago by: Single Stage to Orbi

I wish aeroplanes had parachutes for those "oh shit" moments.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 9 Hours ago by: Arne_Vajhøj

Short term correct. But long term no. Long term they want the real thing. Sure sometime it take decades to complete the move. But as soon as X is deemed not the long term target, then new development get done on Y if possible. It starts

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 9 Hours ago by: Dave Froble

My position is they were ALWAYS broken ...

DCL vulnerability, was: Re: The hardware support problem for x86

comp.os.vms

Posted: 1 Day 10 Hours ago by: Simon Clubley

Hello Jake, I'm the person who found the DCL vulnerability. There was never a patch developed for VAX that I am aware of, unless some consultant did it privately. There was a workaround, which was to disable CDU access for normal users.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 1 Day 11 Hours ago by: Simon Clubley

Parachutes are a required feature so people don't die. You also make sure they are built to required safety standards. No, but you ban the ones that are no longer safe. Likewise, there are very good reasons why Hollerith constants are

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 11 Hours ago by: Kerry Main

Conversely, it makes it very difficult to switch from X to Y if X can do the same as Y. Especially if the cost to switch is years and during the transition, will have severe impact on new functionality being requested by the business.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 1 Day 11 Hours ago by: Simon Clubley

Person who likes Ada here, remember ? :-) I always care about my types... :-) Simon.

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 11 Hours ago by: Kerry Main

Another similarity is that OpenVMS and z/OS is are both active-active, shared disk file systems. Walk down memory lane - "the best clusters on the planet have the same 3 letters" .. VMS and MVS (aka z/OS). 😊 Regards, Kerry Main K

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 12 Hours ago by: Bill Gunshannon

40 years ago those names had meaning (in the IBM world). They remain the same today out of momentum. Unix 's curt naming dates to a time of 110 Baud communications. Today "cp" could easily be "copy", "ld" could be "load" and "ls" coul

Re: VMS article in The Register

comp.os.vms

Posted: 1 Day 17 Hours ago by: Jan-Erik_Söderholm

Just look at the definition for "IEFBR14" to get an idea of the utterly bizarre naming conventions of the standard system programs that you can run from JCL: https://en.wikipedia.org/wiki/IEFBR14 I have written quite some JCL that use

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 20 Hours ago by: Dave Froble

Where can I find a hat like that one you pull all those numbers and such from?

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 20 Hours ago by: Dave Froble

Goes both directions Arne ....

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 22 Hours ago by: Arne_Vajhøj

The difference between Cobol/mainframe -> Cobol/newer and Cobol/mainframe -> newer/newer is not that big. So it describes why not migrating at all is pretty attractive. The cost and risk of big conversion projects is big. Most CEO/CFO/C

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 22 Hours ago by: Arne_Vajhøj

True. But you seem to be missing the point. It is not like Cobol->Cobol is a 1 week project and Cobol->X is a 6-12 month project like you described. Both are 18-24 months projects. And due to all the common work Cobol->Cobol may be 30

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 22 Hours ago by: Arne_Vajhøj

Lines of code does matter cost wise. It is not the time to type it in, but the time to read it that matters. The world evolve and requirements for systems evolve. The size of required library code for a current application for a given

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 22 Hours ago by: Arne_Vajhøj

It is obviously easier for interpreted languages, but that just gives these languages an advantage. It does not change the industry expectation. Arne PS: Basic is mostly compiled today. VB.NET, VB6 and VMS Basic are all compiled. V

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 23 Hours ago by: Arne_Vajhøj

As a general rule if the best argument for buying X is that it is able to do the same as Y, then most will prefer Y over X. Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 1 Day 23 Hours ago by: Arne_Vajhøj

It is not clear to me in what case you think the difference is big. Arne

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 2 Days ago by: Arne_Vajhøj

I had never seen that. But I am not sure that I will call that passing type of argument. It identifies arguments that are F, D, G, S and T floating point. All the rest is bundled together: 8/16/32/64 bit integers, booleans, string desc

Re: VMS article in The Register

comp.os.vms

Posted: 2 Days 1 Hour ago by: Jake Hamby

IBM has some very impressive achievements as far as uptime (7 nines), backwards compatibility, and hardware acceleration for everything from COBOL (SIMD decimal, hexadecimal, and IEEE floating point and fast numeric format conversions) to

Re: VMS to VMS data copy options/performance when losing a DECnet (thread)

comp.os.vms

Posted: 2 Days 9 Hours ago by: Tad Winters

I'm so behind in reading that I haven't followed closely, but I think you were transferring save sets, but I don't recall seeing all the qualifiers you used. Years ago, I recall using /GROUP_SIZE=0, overriding the default size of 10. Th

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 2 Days 9 Hours ago by: Kerry Main

As others have stated in this thread, there are pro's and con's with every compute strategy. The distributed vs. centralized architecture wars have been going on for 40+ years. However, do not under estimate the allure of centralized, h

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 2 Days 10 Hours ago by: chris

Cover quite a bit of ground there, but in summary, every site needs to have techs familiar with the use of network sniffing tools like Wireshark, tcpdump etc and know how to interpret the results. With ever greater system complexity, the

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 2 Days 11 Hours ago by: chris

Probably right about Itanium and Arm, for opposite reasons of course. Limited experience with Power series, though was quite impressed with a power series server some years ago. Also liked aix 6 as a fully sorted os and the hardware const

Re: Looking for Dell Unity Sites (thread)

comp.os.vms

Posted: 3 Days ago by: Stephen Hoffman

TCP/IP Services V5.7 with recent patches is minimally adequate for most ssh uses. Folks using ssh will probably V5.7-ECO5o or later. As per usual, check with VSI for the current patches for SSH. The availability of OpenSSH is in prog

Re: Looking for Dell Unity Sites (thread)

comp.os.vms

Posted: 3 Days 1 Hour ago by: Bob Gezelter

Robert, OpenVMS SSH (at least the VSI TCP/IP 5.7 version) is very behind on support for encryption. Have had similar issues in other contexts. First suggestion: When initiating an SSH connection, use the option that enables full trace of

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 3 Days 2 Hours ago by: Jake Hamby

You might enjoy this 2018 CppCon talk by JF Bastien at Apple about how C++ actually works in practice and the effort required to finally guarantee signed integers to be two's complement there so that the compiler will generate the code th

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 2 Hours ago by: Jake Hamby

There's a good argument for Itanium for that purpose (perhaps the only good argument left for Itanium these days). The DCL vulnerability reported in early 2018 was patched for VAX, Alpha, and Itanium, but the Itanium patch was to protect

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 2 Hours ago by: IanD

Yep, pretty much what ETL (or the more funky modern incarnation, pipeline) conceptualizes. On a project currently that will literally take about 18-24 months just to clarify a formal technical design after data/analysis emerges from a po

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 2 Hours ago by: Jake Hamby

The Supermicro story seemed like someone's planted FUD to me, given how emphatic the denials of Apple, Google, and of course Supermicro were. Anything's plausible. I'm surprised that non-US companies are so willing to buy American hardwar

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 6 Hours ago by: chris

That's the ideal, baut can cause issues if if you are running a web server or other external services. Get round that here by using old Sparc hardware, on the basis that many intrusion exploits depend on getting an executable binary loade

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 8 Hours ago by: chris

Still looking into that, but looking for something equivalent to dl360 and dl380 Proliant. Basic spec, 2 x I5 processors min and options as per the DL... series. Never buy new here, but X3550 M4 or M5 look far enough down the price curve

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 8 Hours ago by: Bill Gunshannon

All true. But none of it has anything to do with the COBOL. And a lot of it would be more work when moving to a new language. Moving the COBOL would be fairly trivial and all the rest will be the same or worse if you are changing languag

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 8 Hours ago by: Bill Gunshannon

The only problem would be the possibility that they have been coerced into doing it by the Chinese government. Not paranoid, just aware of the current situation. Same as the report on Lenovo 15 years ago. It definitely wasn't NSA as t

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 9 Hours ago by: Scott Dorsey

[regarding supermicro] That report was a bit over the top when it came out and has since been pretty well discredited. However, even so, many government agencies are still barred from buying Supermicro hardware. This is enough of a rea

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 9 Hours ago by: John Reagan

I have asked for it to be moved up. Even with the PIPE driver (cousin of the mailbox driver), I still see the record orientation showing up when I do something like $ pipe anal/obj/section=symbol | search sys$pipe symbolname

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 10 Hours ago by: chris

Fwics, a lot of kit is manufactured in China these days, but at least with a vendor like IBM or even HP, I would trust them over some others, as they will have processes in place to ensure security at hardware level. All levels of manufac

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 10 Hours ago by: Craig A. Berry

Thanks, and I get it -- your priorities are where they need to be for now.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 10 Hours ago by: John Dallman

The last time I bought low-end POWER servers from IBM, they were made in China. So I think you can expect anything x86-based to come from there too. John

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 10 Hours ago by: Bill Gunshannon

That only mattered when resources like memory and disk space were at a premium. And, don't throw out the red herring about how much longer it takes to type the program in. With modern IDE's (well, not very modern as we had them on the V

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 10 Hours ago by: Bill Gunshannon

Another example of being ahead of their time. like STVOS/POSIX. Java fits this category. But not the others. If you are going to include interpreted languages then BASIC wins hands down. bill

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 11 Hours ago by: Bill Gunshannon

One would hope by now that people have learned to keep production systems isolated from the internet. That keeps them from reporting back. :-) If nothing else, monitoring by your competent network people :-) would identify this and it

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 3 Days 12 Hours ago by: chris

There was also the report in the Register and elsewhere about the possibility of management processors that reported back to China. Just the possibility of spyware in hardware would make me think twice about using such machines. With eng

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 19 Hours ago by: Stephen Hoffman

Ah, okay. You were adding features, and not actually fixing things. I got confused. My bad. Objective C already provides this, and very nicely. Or available with a migration to C++ for that matter, too. But by all means, please do g

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 20 Hours ago by: John Reagan

I'll double check. I might be thinking of the additional call signature relocations at external calls which might resolve to translated code. Huh? There is the Argument Info Offset at at bit 47 and then CS talks about what the AIB looks

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 20 Hours ago by: John Reagan

The x86 cross-compilers are all 32-bit pointers including the LLVM pieces. For the native compilers, the frontends and GEM pieces are still 32-bit pointers. The GEM-to-LLVM is now 64-bit pointers and LLVM itself is compiled with 64-bit p

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 20 Hours ago by: Dave Froble

Do that, and someone like Simon will get in there and break some things. :-)

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 20 Hours ago by: Dave Froble

Uh, didn't you just describe why changing to another language is such a bad, expensive, and dangerous thing to do?

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 20 Hours ago by: Dave Froble

Only if very good specifications exist. Trying to figure out what code is doing, and it's worse if you aren't very good in the old code, rarely ends well. You may claim different. Doesn't make you right. I've seen it. I've experien

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 21 Hours ago by: Jake Hamby

Hmm, this seems to be a regression in x86-64 compared to Alpha and Itanium. VSI Calling Standard 3.6.1. Call Conventions: https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32 See Figure 3.10. Argument Information Register

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 22 Hours ago by: Jake Hamby

That's good to know, thanks. On further inspection, the compiler ran out of heap memory. I watched it with ^T and it crashed after growing to around 1643 MB (210368 pages). /OPT=4 is perfectly fine for me. I'd guess that there's had to h

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 23 Hours ago by: John Reagan

/OPT=5 was always a work-in-progress when the Alpha work was stopped. There was several places where it generated slower code than /OPT=4. That's why 4 was left as the default.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 23 Hours ago by: John Reagan

Only if you compile /TIE (which is not the default).

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 23 Hours ago by: Arne_Vajhøj

If system migration is just taking a Cobol program with mostly ANSI Cobol and get it to build and run on a new platform then it is not a big thing. But that is not how a system migration look like in real life. You have N Cobol pieces,

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 23 Hours ago by: John Reagan

I haven't forgotten about it. It isn't in yet as we've been focusing on other things for the most recent ECOs.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 3 Days 23 Hours ago by: Arne_Vajhøj

* more powerful language (fewer lines of code per functionality) * more powerful libraries * better isolation making changes less risky [not sure whether that applies to Python - consider that more a JVM / CLR language thing] * bett

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days ago by: Arne_Vajhøj

It certainly passes the number of arguments. But type?? Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days ago by: Arne_Vajhøj

It works today. I would guess that 2/3 of all the worlds developers develop and test (not via simulator) on a different platform than their final target. Java, PHP, Python, JavaScript etc. developers write their code on Windows or macOS

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days ago by: Arne_Vajhøj

If 32 bit is truly required then yes. But if the system has 36 bit int's and they would work then it is a different story. Egg on my face. Of course unsigned does not specify how negative numbers are represented. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days ago by: Arne_Vajhøj

They sell a lot of servers. Their servers may be just as good as what HPE and Dell sells. But I don't think they have the brand name that at least some VMS shops may require. Arne

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 4 Days 1 Hour ago by: Stephen Hoffman

I'd try calling IO$_DIAGNOSE directly, and passing along the necessary SCSI commands, and reading the responses from the tape drive. Tapes aren't particularly complicated, as SCSI goes. You'll probably wedge something the first few ti

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 4 Days 1 Hour ago by: gah4

(snip) There was a story once about someone writing such a tape on an IBM S/360 machine. The OS won't do that, but if you write your own channel program, and use data chaining, it is supposed to be possible. Data chaining allows multipl

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 1 Hour ago by: Bill Gunshannon

How would adding a string type break null terminated strings? One could still use them but a safer option would be available. And then time and inertia would eventually eliminate the bad practice. Bounds checking? Even if it were to br

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 4 Days 1 Hour ago by: chris

Interesting. Again, we are reminded of the joy of unix, tar, dd etc... Chris

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 2 Hours ago by: Dave Froble

There are words to describe that type of thinking. "Tyrant" comes to mind. Should we do away with parachutes so people cannot sky dive? Should we do away with cars so people cannot crash?

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 4 Days 2 Hours ago by: Stephen Hoffman

That's true in C until C2X, with the current draft requiring two's complement, and including type-generic functions for integer overflow checks. Same here, where I need to care that much about the integer types.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Stephen Hoffman

Just a guess: probably because the C committee is not entirely comprised of pendejos. While the C committee could make such changes, those changes would break enough existing C code that there'd be little reason not to break yet more

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: abrsvc

Thanks, I will keep this in mind. The version in this case is V8.4-2l2 (VSI version) and the issue was the journal size being in the millions of blocks when normally it is around 200 or so. The file was kept, I just haven't had time to

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Craig A. Berry

I'm pretty sure that one is just using heap memory to do its own buffering around a mailbox pipe, but I confess I've never looked at it in any detail. dmpipe uses global sections, which is really what the CRTL should have switched to d

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Peter Weaver

If you're running VMS 6.2 then I highly recommend having a batch job that runs once a month (or week, or quarter depending on your needs) that does a simple; $ directory/size=all CLUSTER_COMMON:SYS$QUEUE_MANAGER.QMAN$JOURNAL $ mcr jbc$comm

Re: [OT] Today's date and also the future (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Stephen Hoffman

All DEC/Compaq/HP/HPE-signed layered product software installation checks will fail to verify the kit signatures, and the checks must be overridden to permit installations. VSI is using their own signature AFAIK, which would mean ther

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Stephen Hoffman

I've suggested SuperMicro as an alternative to HPE and Dell, and with a very large selection of servers.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Stephen Hoffman

For projects ranging from refactoring to a full overhaul, consider adding preprocessor #define commands to cause certain entirely valid but too-often problematic C calls to generate errors. (e.g. sprintf, strcat, strcpy, etc) https:/

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Jake Hamby

I had to jinx myself: after I wrote that, I managed to get an internal compiler error in VSI C V7.4-002 on the Alpha by building rexx.exe with /PLUS_LIST_OPTIMIZE and /OPT=(LEV=5). I assume I managed to overflow some internal inlining log

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 3 Hours ago by: Jake Hamby

I agree with everything you just said. Aha, that's where I should look for a faster pipe implementation, thanks! I saw something similar to dmpipe in the GNV bash port ("vms_vm_pipe.c"), but it didn't come with docs or test programs, so

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 4 Hours ago by: Jake Hamby

Well, C is very much in the "worse is better" spirit of software design that Richard Gabriel coined in 1989, to contrast with Lisp and other designs that focused on correctness rather than "move fast and break things". C++ is the way it

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 4 Hours ago by: Bob Eager

I have a standard 'typedefs' file that I use for all my C programs. For example: typedef int INT,*PINT; At least I can make adjustments easily, although one has to be careful in lots of other places (e.g. shifts).

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 4 Hours ago by: Jake Hamby

Lenovo's pretty good at making PCs. I fully understand and support IBM offloading their x86 business, because it wasn't going to generate sufficient profit margins for IBM's sales-heavy business model. They've been focusing completely on

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 4 Days 5 Hours ago by: Rich Alderson

Multics was developed on the GE 645 (an extended 635) in the mid-1960s, in the MIT lab which created CTSS on the IBM 7094, so I suppose you could call them "IBMers" but I wouldn't. Funding came from GE (later Honeywell) and AT&T. PL/

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 5 Hours ago by: Bill Gunshannon

I started as a night shift operator on an IBM 1401 in Germany in my first Army days. A senior NCO used to come in and run a program at night that took several hours. During that time he was nice enough to teach me Autocoder. Then I got

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 5 Hours ago by: Johnny Billquist

Well, if the system don't have 32 bit integers, then the code is doomed to fail anyway, and it's good that it fails at compilation. I would hope that an uintN_t is guaranteed to *not* be two complement. It would sortof defeat the mean

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 4 Days 5 Hours ago by: Johnny Billquist

That won't help. You cannot read a block larger than 64K under VMS. And with tapes, after reading a block, even if not complete, the drive then moves to the start of the next block, and the remaining part of the previous block is just

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: Chris Townley

I know what you mean! I actually started in a small way in 1965, being taught (without access to a system) some form of assembler - aged 13! That along with binary logic was very useful later

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: Arne_Vajhøj

Which is as good as you can do in C. But note that their existence is optional, if the system does not have 32 bit integers then they don't exist. And intN_t is guaranteed to be two's complement but uintN_T is not. Arne

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: Arne_Vajhøj

The languages that started this thread certainly did not mimic existing languages. Rust - low level, well defined types (bit size), generic programming, closures, safe/unsafe mode, memory ownership model, traits, type inference etc. Go

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: Simon Clubley

These days, I avoid this problem in my C code by using the uint[8/16/32]_t (and friends) data types. Simon.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: chris

Have no experience of the G9 and up series, but they will be just an incremental development of the range. There is a lot of built in capability in DL380. One or two multicore processors. Memory is all ECC with iirc, interleaving and othe

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 4 Days 6 Hours ago by: Simon Clubley

Because you want to remove dangerous features to force people to write more robust code. Hollerith constants (for example) have been removed from all current Fortran compilers and for _very_ good reasons. Sometimes yes, sometimes no.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Arne_Vajhøj

So you like the choice of DL380 as first supported physical? Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Arne_Vajhøj

Low height rack mounted Alpha. https://people.freebsd.org/~wilko/Alpha-gallery/DS10L/dcp_0589.jpg I would expect practically all developers to use VM. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: chris

The dl two digit are generally the low end Proliants. The DL320, DL360 abd DL380 are more the industry standard types, with a very wide range of options. That's rack mount, but for deskside, the MLxxx series apply and have more card slot

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Jan-Erik_Söderholm

On the desktop I expect that a VM work better. Then you still have your usual "office" environment there also. And desptop systems are probably not the best for a "server".

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Michael S

They, may be, not much more powerful than biggest Itanium Superdome of the latest generation, may be, even somewhat less powerful in some aspects, but, according to my understanding, VMS never was capable to run on fully-loaded Superdome

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Bill Gunshannon

True, but some of what I mentioned isn't limited to compilers or just K&R code. Why didn't ANSI fix some of the problems like null terminated strings, requiring bounds checking, etc. when they had the chance? bill

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 7 Hours ago by: Bill Gunshannon

Porting COBOL from one system to another is something I have played with. I have yet to find a case where the COBOL (not DB or CICS or any other add on) took more than a couple hours to port. Almost all of the commercial offerings (espe

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Bill Gunshannon

Thank you. That's what I figured. It shows. Oh, and if you don't get it, that is a compliment. It was the 1980 when I really got into IT even though I actually started in the very early 70's. We learned a lot of things different (I th

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Arne_Vajhøj

You could not write the software of today without it. Java did not invent GC, but it was the first really widely used language using it. FP today is pretty well defined. Methods expecting functions, callers specifying lambdas, optiona

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Arne_Vajhøj

The point is that backwards compatibility requirements impact what languages can do. And that sometimes makes it better to start from scratch. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Arne_Vajhøj

I thought DL380 was starting around 5 K$. Which is not an unreasonable starting point for a VMS system. But yes - they may be more powerful than last Itanium's that are really an decade old design. A DL20 is the "DS10L lookalike" starti

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Michael S

Fully-loaded DL380 G10 (even without Plus) is probably bigger than anything VMS was ever running on, both in terms of memory size and in terms of # of cores/threads. In bare metal scenario I would expect surprising scalability hazards. A

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Arne_Vajhøj

A lot of things is possible. New compilers could be developed. Some compiler existed 30-40 years ago. But that does not help those with K&R C code today. They have the compilers they have. And based on how the state of world actually ar

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Chris Townley

80s

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 8 Hours ago by: Arne_Vajhøj

I have not heard about companies porting Cobol/VMS to Cobol/Linux. But there are companies doing Cobol/IBM mainframe to Cobol/Linux and even Cobol/Unisys mainframe to Cobol/Linux. I don't think you will see those one week Cobol to Cobol

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 9 Hours ago by: Bill Gunshannon

So, tell me, what year did you start in the IT biz? bill

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 9 Hours ago by: Chris Townley

In our team, it as required for any Vax/Dec Basic modules. I also frowned on assuming default initialisation of variables, and would pick it up in any code review

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 9 Hours ago by: Dave Froble

See, already an option. But, I'm not too fond of the concept of "enforce". I'll do my own enforcing.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 9 Hours ago by: Dave Froble

Why would you want to remove something that perhaps some users want to continue to use? Leaving it doesn't hurt, and users can choose to not use it. Starting with something existing is easier than starting from scratch. There is not

Re: Looking for Dell Unity Sites (thread)

comp.os.vms

Posted: 4 Days 10 Hours ago by: Ian Miller

which version of SSH are you running on which version of VMS on what architecture? HP TCPIP V5.7 is very out of date

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 10 Hours ago by: Bill Gunshannon

Yes, but the point was that it could be. Just like they could have come up with better string handling libraries which over time could have found their way into the CRTL. Heck, ANSI could have come up with a defined string that was not

Re: [OT] Today's date and also the future (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Simon Clubley

19-May-1997. Do you know what the practical effects of that one will be for VMS sites ? There was also an old SPR or problem report where something would fail around the year 5xxx (IIRC). The answer said the problem would be fixed som

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Bill Gunshannon

Of course they would. But not for the reason you would think. Too many places let their IT departments die by attrition and now no longer have the staff to even handle maintenance on their legacy stuff. Places that do are the ones not l

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Bill Gunshannon

Thus what I meant about background, education and experience being great influencers. I, personally, do not believe in IMPLICIT anything. Even in Fortran I always explicitly declared all of my variables. Trust no one, especially compilers

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Bill Gunshannon

They could have written it in PL/M. Even Ada or Pascal. No task is limited to just one language. Part of Software Engineering is supposed to be picking the right tool for the job. Never having played with Multics source I can't say wh

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Arne_Vajhøj

It is not a technical problem to implement but a customer problem. I am sure John Reagan could make the change in 10 minutes. But VSI would need to get him bodyguards for the rest of his life to protect him against angry VMS Basic users

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Chris Townley

Easy - just enforce OPTION TYPE = EXPLICIT

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Bill Gunshannon

No, existing languages can and do evolve. Turbo Pascal was greatly enhanced from the Pascal described in the Jensen & Wirth book. Many enhancements like an actual string. Sadly, because of abuse of the original language he had to creat

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 11 Hours ago by: Arne_Vajhøj

No, because that happens. Fortran 66 to 77 added if block and character type (and changed semantics of do loop). C 89 to 99 added declaration anywhere and // comments. Java 1.4 to 1.5 added enum, annotations and generics. Java 1.6 to 1

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 17 Hours ago by: David Wade

These days I would say HP is the best of a bad bunch. The realistic alternatives? Well DELL who change specs at the drop of a hat, and Lenovo who kind of carried on from IBM so totally Chinese? Dave

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 4 Days 17 Hours ago by: JKB

No in a short future, but I will try. JKB

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 21 Hours ago by: Craig A. Berry

It's going to remain an open question for some time. As far as I know, none of the cross compilers has optimizations turned on, which means there is no optimized code in the OS or libraries shipped with the OS, much less in anything yo

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 21 Hours ago by: Dave Froble

Are you saying existing languages cannot evolve, and get new and better capabilities? A while back this happened to DEC Basic. Lots of enhancements. Afraid I have to agree with the "ego" thing ...

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

The wrote Multics in PL/I and OS is supposed to be C core competency. You may not like OOP but most do. Then there is generic programming. Functional programming. Automatic garbage collection. Reflection. Well defined types. I have pro

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Alan Frisbie

I have seen the same problem with backup tapes from Windows machines, but our solution was to simply change the Windows software to not write such big blocks. As I recall, the problem was that the VMS I/O driver simply couldn't handle mo

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

Sure. But there are companies out there that do it for living. Porting real applications for real companies. I doubt they would exist if it was so easy. There are success stories doing that. Maybe one of the most portable languages

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

So there was something available 30-40 years ago. That does not help anyone today. Because those people with C code want to build their C code - they do not want to write their own compiler. They have to use the C compilers that are ac

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Bill Gunshannon

Yes, there was. I have mentioned it here numerous times. It was called Safe C and was available on both the PDP-11 and VAX. And, apparently, the industry resoundingly rejected it. Why is that? GCC was written from scratch. It was no

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Bill Gunshannon

In many of the cases I have played with that is more trivial than you imagine. I have done a few (mostly trivial example programs as no one is likely to give me production code to play with) in my research. That's a potential disaster

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

I was talking about migrating from Cobol/mainframe to Cobol/non-mainframe above. Which is what is relevant for the "just recompile" discussion. There are also those that migrate from Cobol/mainframe to newer language/non-mainframe. But

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

They all try to address some known problems in old languages. The problems are identified and they fix them. But that does not guarantee that they overall are better than the old languages. And in case there are multiple that are better

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Bill Gunshannon

Trust me, no you don't. The only good news I got was that I don't have COVID. Went in for knee surgery. Got to the OR. Everybody jumped up and yelled "April Fool". Got a free ride to the ER and 3 fun filled days in the hospital. Not

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

Many things are possible. But are there any really good checking K&R compilers available? If not then the fact that one could be written is not that useful. Arne

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Arne_Vajhøj

Nobody pick OS based on benchmarks today. Speed is not the issue. Software bugs and vulnerabilities are the issue. More code means higher risk. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 4 Days 22 Hours ago by: Bill Gunshannon

And yet there was a time here when it was thought that VMS was going to die that these same people all said they would never by anything from HP again. Go figure. (Don't get me wrong. I am typing this right now on an HP All-In-One PC r

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 4 Days 23 Hours ago by: Bill Gunshannon

None of those languages do what the Wirth and K&R languages do. Ignoring the fact that people took Pascal and C and proceeded to use them for things they were not designed for and for which there already were perfectly good languages. Wh

Re: [OT] Today's date and also the future (thread)

comp.os.vms

Posted: 5 Days ago by: Arne_Vajhøj

The last two does not worry me so much. :-) Arne

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 5 Days ago by: Arne_Vajhøj

Programming languages is very much a matter of evolution. New languages show up all the time. Those that are good replace older languages. Those that are not good dies. What if Wirth and K&R had decided in the late 60's that Fortran, Co

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days ago by: Arne_Vajhøj

Yes. It had to be a brand name so HPE or Dell. VSI got a business relationship with HPE so HPE. It had to be a widely used model at an appropriate mid size. DL380 seems like a fine choice. Arne

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 5 Days 1 Hour ago by: Jake Hamby

I'll put together a standalone test case. BTW, I forgot to mention this would be the __memset() builtin provided by the C compiler and not the one in the CRTL. I haven't tested the non-builtin memset yet.

Re: Maximum magtape block size (thread)

comp.os.vms

Posted: 5 Days 2 Hours ago by: abrsvc

I would look for answers to two questions: 1) Is the blocksize known? 2) Is the size consistent for the entire tape? If the answer is yes, mount the tape foreign and read a fixed blocksize that VMS can handle and build up the file as nee

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 2 Hours ago by: John Dallman

In the late 1990s, when I was new there, my employers were testing the same software regularly on three different Alpha platforms: 32-bit VMS, 32-bit Windows NT, and 64-bit OSF/1 UNIX. As best I remember, the OSF was fastest, with Window

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 2 Hours ago by: Jake Hamby

That's a mean thing to say, but it's a big open question (at least for me, since I don't have access to the x86 version): how well does VMS actually perform on modern x86-64 hardware? I don't think VSI did themselves any favors by demoin

Maximum magtape block size

comp.os.vms

Posted: 5 Days 2 Hours ago by: Mark Berryman

I've been trying to find a way to read tapes written on other systems that use a block size somewhat larger than 64K (usually 128K). The 64K limit on VMS *seems* to be caused by using a 2-byte field for the DMA buffer size but perhaps t

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 2 Hours ago by: Jake Hamby

I completely agree with everything you said, and thanks for the suggestion of useful warnings to enable. I've been working on reviving the OpenVMS port of Regina (Rexx interpreter), which has been great fun (I have a strange sense of fun

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 2 Hours ago by: Stephen Hoffman

The following prior to the availability of the planned VSI hardware buyer's guide. From previous postings by VSI folks here in the comp.os.vms newsgroup, the initial native-boot hardware target is ProLiant DL380 Gen 9 and later. I'd

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 3 Hours ago by: Dave Froble

My, Bill is kind of feisty these days. Wonder what they gave him in that hospital? Have to get me some of that ... :-)

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 3 Hours ago by: Dave Froble

Well, it really sucks when all your options are poor to bad options. Sometimes one must sort the options, and pick the least poor one. From my perspective, which is way back in the cheap seats, HPe produces some reasonable x86 server

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 3 Hours ago by: Stephen Hoffman

You're one of the most adorable folks here. That you continue to contribute your wealth of knowledge and insight and experience is a gift to all of us. And by all means, please do scope your projects and price your project work howeve

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Michael S

Right now "HPE DL380" means two quite different machines: Gen 10 and Gen10 Plus. And yet different Gen 11 is planned for 3rd or at worst 4th quarter. Which one of the three is supported by VSI?

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Bill Gunshannon

But that's a compiler (or programmer) problem and has nothing to do with K&R beyond the age of the language definition. A lot was left out in the bygone era because of the limits on resources. There is no reason, today, why th compiler c

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Bill Gunshannon

Are we talking compilers or language? No one is using PCC any more. And a modern compiler could not generate those warning for K&R? Note, I said "could not" not doesn't. And what does that have to do with the language? That's a comp

Re: [OT] Today's date and also the future (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Stephen Hoffman

They've already been occurring. Closer to the comp.os.vms newsgroup, DEC found and fixed at least one time_t overflow bug in OpenVMS, that though 2038 was outside the Y2K review. I expect we're headed for another Y2K-style review a

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Bill Gunshannon

No idea as I am not in the market and it is a rapidly moving target. I was just pointing out the fact that for years now people here have considered HPE the enemy but they kinda want to still put money in their pocket. Kinda like having

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Bill Gunshannon

Just what the industry needs. A few more ego languages. bill

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 4 Hours ago by: Stephen Hoffman

Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs. K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for adding code bugs, and that compilation usually also with YOLO-grade diagnostics settings. Cl

[OT] Independence, was: Re: The hardware support problem for x86

comp.os.vms

Posted: 5 Days 5 Hours ago by: Simon Clubley

Your country is doing a damn good job of allowing ideology to destroy its future independence and the ability to continue to be the master of its own destiny. :-( Mind you, certain parts of Europe are turning out not to be all that great

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 5 Hours ago by: Simon Clubley

Because of what the compilers let you get away with back then and also didn't even bother to warn you about so you could realise there was a problem and fix it. These days, you get a lot more compiler errors and warnings and code is bett

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Bill Gunshannon

All the more reason I would shun Software Engineers in favor of old fashioned Programmer/Analysts. Promising what? Aren't they just solutions searching for a problem? Or new ego trips. bill

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Bill Gunshannon

Sorry, based on what I saw in a place with a Masters Degree Program in SE I would take a good old fashioned Programmer/Analyst over a Software engineer any day. Actually, there is another one that was ideal but never found its way into

[OT] Today's date and also the future

comp.os.vms

Posted: 5 Days 6 Hours ago by: Simon Clubley

I thought today's date was familiar and then I realised it's exactly 25 years ago today since the 10,000 day delta time issue. I am now depressed that I am now old enough to have events in my professional life from 25 years ago... :-( or :

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Bill Gunshannon

Thank you. You beat me to it and said it more eloquently than I would have. bill

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Bill Gunshannon

What makes the code inherently unstable just because it is K&R as opposed to the crap being written in the more modern languages? bill

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Simon Clubley

Did you have any luck trying an older version of axpbox with HPE VMS ? Simon.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Bill Gunshannon

Might work. Until the first time you have to run a benchmark. bill

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 6 Hours ago by: Simon Clubley

They had to pick _a_ server for their initial hardware target. Which one would you have suggested instead ? Simon.

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 5 Days 7 Hours ago by: Chris Townley

Just installed this upgrade and it works well. Not sure how it will affect the VMS performance - Bruce does warn about this, but neither is a core maxed out! There is a new checkbox in the config you need to set.

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 5 Days 8 Hours ago by: Chris Townley

Migration Specialities now have a fix for 100% usage of one core/thread, but said it doesn't yet work on VSI 8.4-2L1 However on 25th April: I intend to upgrade! Chris

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 5 Days 8 Hours ago by: JKB

I have upgraded 8.4 (HPE) to 8.4L1 (VSI) to try to use a VSI license (and I have asked VSI if its icommunity license can be used on ES40. Answer : yes, of course). If I cannot install OpenVMS on axpbox, I will try to restart my ES40.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 9 Hours ago by: Bill Gunshannon

Because it's an easy target. Managers today have all heard of Java and Python. Most have probably never heard of COBOL or seen so much as on example. There is more money to be made in getting people to move, whether it is a good idea o

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 5 Days 9 Hours ago by: Bill Gunshannon

Sorry, I should have said that old rolling stock has less costs. New rolling stock has maintenance costs, too, but also has the cost of purchase over the already paid for (and costs recovered thru depreciation) old rolling stock. Cute c

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 9 Hours ago by: Bill Gunshannon

Wasn't it the Canadian Atomic Energy people looking for PDP-11 experience not to long ago? Now that it is gone completely, I wonder what Three Mile Island was running? And the local Nuclear Plant is (I think) in the process of being pha

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 5 Days 11 Hours ago by: Bill Gunshannon

Ah yes, lets continue to rely on the company we have despised for so long because of their unreliability. That bodes well. bill

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 5 Days 11 Hours ago by: Bill Gunshannon

The only "main version" is the original. Anything else is just a cheap copy. bill

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 5 Days 11 Hours ago by: Bill Gunshannon

I was going to comment on this but have been out of the loop for a few days (another bad hospital stay, sigh...). I only use the orignal Supnik version and avoid all the drama. But then, as everyone here probably already knows, I still

Looking for Dell Unity Sites

comp.os.vms

Posted: 5 Days 12 Hours ago by: Rob

Hi all. We have a new Unity SAN that’s we’re trying to get running, but I’ve run into a problem with SSH. Is there anyone else out there running a Unity? It doesn’t have to be attached to OpenVMS as this has nothing to do with the

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 2 Hours ago by: Stephen Hoffman

Or more specifically, I'll get an opaque 64-bit value that looks and works like a virtual address, but may or may not represent the actual virtual address of the target instruction. An opaque 64-bit virtual-address-like value which ma

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 2 Hours ago by: Dave Froble

Sure was for me, cause I still have a Macro-32 application (database) in use. Without that I would never used Alpha or itanic.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 3 Hours ago by: hb

OK, I should have said, on x86 and IA64 function pointers always contain 32-bit values. Or, whenever you take the address of a function, you will get a 32-bit address.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 3 Hours ago by: Stephen Hoffman

More than a little of which is code necessary to work around other backward-compatibility efforts, not the least of which is defensive app coding around against the DECC$ feature logical names. That case could be made. From out here

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 3 Hours ago by: Stephen Hoffman

Though AFAIK the user works with a 64-bit value for the function pointer, and doesn't ever see the internal limitations nor the use of a trampoline where that's needed. I don't have an Itanium handy to test and E9.2 isn't playing nice

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 3 Hours ago by: Arne_Vajhøj

I obviously don't know what all VMS systems are used for. :-) But if I use my crystal ball and my best RNG and divide with the current local temperature and multiply with the date I see the following. current VMS users: 20% use 64 bit

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 6 Days 4 Hours ago by: Arne_Vajhøj

I believe there is strong interest in SIMH. That means it will not collapse. Either they will work it out or it will be forked and the fork will become the main version. Arne

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 4 Hours ago by: Hans Bachner

Try write sys$output f$getsyi("ARCH_NAME"), ">" Is there a trailing space behind "Alpha" and before the ">"? In a previous post you mention: This is strange. My hobbyist license has /ACTIVITY=CONSTANT0 in its definition and LMF re

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 5 Hours ago by: John Dallman

Also many kinds of mathematical modellers, simulation systems and graphics programs. They can be done as 32-bit programs, but they just can't hold enough data in a 32-bit address space for big jobs. Certainly are. They will. John

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 5 Hours ago by: Simon Clubley

Applications increasingly need access to the additional address space that 64-bit processors gives them. Simon.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 5 Hours ago by: Simon Clubley

So you admit the need to support Macro-32 applications was a requirement ? :-) Alpha needed to run VAX applications, but because of how VMS was designed, DEC had to make some very ugly design decisions for VMS on Alpha. These are thing

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 5 Hours ago by: Simon Clubley

The loader has no knowledge of whether the image uses 32-bit pointers or a mixture of 32-bit and 64-bit pointers. On VMS, that, and whether the program calls 32-bit VMS APIs only or a mixture of 32-bit and 64-bit APIs is purely an interna

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 6 Hours ago by: Dave Froble

Ok, then just what is the issue? Calling it "serious" doesn't define it.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 6 Hours ago by: Dave Froble

Correct. And remember, some strictly 32 bit apps are supported, as per initial planning. Perhaps addresses are extended. That's not part of an app, as far as I can see. Because this is VMS, not Unix, and some jobs just might need t

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 6 Hours ago by: Simon Clubley

Yes, it's a serious issue. There's a reason why everyone is moving from 32-bit to 64-bit processors for anything outside of embedded type systems. In fact, it's been an issue for decades with servers. The original PRISM design flipped b

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 6 Hours ago by: Simon Clubley

So why do you think that VMS APIs continued to have the size of pointers directly visible in data structures instead of being hidden behind a HLL pointer data type whose size could be changed on demand with compiler options without any ma

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: John H. Reinhardt

"V4" has some nice improvements, not to mention some nice simulator additions. It's going to suck to switch back to V3 and have to hope someone re-ports the good things. (Not me, I can barely spell "C" much less program in it).

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: JKB

Nope. I will try. JKB

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: John H. Reinhardt

Actually it does. At least the HP(E) Hobbyist License does. If you asked, they gave you a VAX/ALPHA compatible set of PAKS and a different set for Integrity.

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: Bob Eager

That someone seems to regard it as his own personal project, and has been riding roughshod for a while. But 3.x is still going strong under the original author.

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: Bob Eager

Indeed. I avoided the V4 fork (which the person who started all the fuss has tried to make the 'official' one) and am basing a new simulator on V3.x.

Re: Simh project about to collapse ? (thread)

comp.os.vms

Posted: 6 Days 10 Hours ago by: John H. Reinhardt

Depends on which version you use. Bob Supnik's V3 is doing fine over at http://simh.trailing-edge.com/ with a new release as of 05-May-2022 with V3.12-2 The "V4" project is the one in danger. Though someone will probably fork it before

Simh project about to collapse ?

comp.os.vms

Posted: 6 Days 11 Hours ago by: Simon Clubley

Just a warning to those of you using simh to emulate various architectures. It looks like the simh project may be about to collapse: https://groups.io/g/simh/topics It looks like the drama started when someone modified simh to write, by

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 6 Days 11 Hours ago by: Simon Clubley

Have you tried using an older version ? It's possible something may have broken in the current version. Which is what would be expected. I think at this point, you need to eliminate the possibility of some kind of emulation problem.

Re: SSL V3 (thread)

comp.os.vms

Posted: 6 Days 11 Hours ago by: Mark Daniel

Well it's not going to get any faster. Apparently this overhead is inherent in OpenSSL 3.0.n "There were significant fixes in the internal algorithm fetching caching which impacts certificate decoding. Unfortunately it will be very ha

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 11 Hours ago by: John Reagan

Yes, the stack is in 32-bit memory. The Calling Standard doesn't directly say that but says the stack starts where the OS says. Since the addresses of stack variables are used in descriptors, itemlists, RMS structs have 32-bit pointers i

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 11 Hours ago by: John Reagan

One small comment on hb's perfect response. The addition of .init_array support on x86 is there only to be used by C++ code. The normal OpenVMS mechanism is the array of 32-bit pointers in LIB$INITIALIZE. And while hb doesn't conside

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 12 Hours ago by: JKB

$ SHOW LIC/CHARGE VMS/LMF Charge Information for node BOHR This is a AlphaServer ES40, hardware model type 1817 Type: A, Units Required: 50 (VAX/VMS Capacity or OpenVMS Unlimited or Base) Type: B, * Not Permitted * (VAX/VMS F&A S

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 6 Days 12 Hours ago by: David Jones

My C code often assumes auto storage class variables (i.e. the stack) are in 32-bit space, but I don't recall seeing that explicitly documented anywhere. I define a macro, RMS_MALLOC, as an alias for _malloc32 since RMS structs are the

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 13 Hours ago by: JKB

I know. I have VAX _and_ ALPHA licenses.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 14 Hours ago by: hb

The image activator doesn't care about the pointer size. Only for shareable images, the image activator calls the code in the LIB$INITIALIZE module, which was (by request) linked into the shareable. Its entry point was written by the l

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 6 Days 15 Hours ago by: Volker Halle

JKB, what does SHOW LIC/CHARGE report ? What does $ LIC LIST/FULL report for Availability: ... Activity: ... Hardware ID: should be empty Volker.

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 15 Hours ago by: Chris Townley

VAX license will not work on Alpha...

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 15 Hours ago by: JKB

HPE license runs fine on a VAX (and simh). For example, on real vax : $ show license vax-vms Active licenses on node FERMAT: ------- Product ID -------- ---- Rating ----- -- Version -- Product Producer Units Avail Act

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 15 Hours ago by: hb

On x86 and IA64 function pointers are always 32 bit. On x86, by default the linker puts code into P2; on request the linker can move code into P0. On x86 the function pointer is a code address of a single code instruction, which uses a

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 15 Hours ago by: Chris Townley

Might be a silly question, but is the old HPE livrnse for Alpha? Are you sure it is not for VAX or I64?

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 16 Hours ago by: JKB

I don't know. I'm trying to use last version (from git). $ write sys$output f$getsyi("arch_name") Alpha $ write sys$output f$getsyi("arch_type") 2 $ Regards, JKB

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 6 Days 16 Hours ago by: JKB

$ write sys$output f$getsyi("ARCH_NAME") Alpha Seems to be good. Nothing : ----------------------------------- Issuer: DEC Authorization: HOBBYIST-VA-... Product Name: OPENVMS-AL

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 6 Days 19 Hours ago by: Dave Froble

I just wonder what percentage of current VMS users need 64 bit addresses. Agreed, it's a "check box" item, better have it.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days ago by: Arne_Vajhøj

Java and C++ programmers should have the same or maybe even higher percentage of sofware engineers as C programmers. Python probably a bit smaller due to the admin scripters and the data scientists. Yes. But somewhere above - long dro

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days ago by: Arne_Vajhøj

There is a reason why Alpha was made 64 bit and not 32 bit those 3 decades ago. There are definitely application types that need 64 bit capability. Databases are one case. And I believe that was the case driving the Alpha decision all t

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 7 Days 1 Hour ago by: chris

Disappointing, but still doesn't amswer the question. Namely, if the code is 32 bit, how does vms know where to put that in 64 bit space ?. The question is relevant, since code has to be loaded at an address, usually defined at link time

Open Source on OpenVMS Conference Call - Thursday 19 May 2022 at

comp.os.vms

Posted: 7 Days 1 Hour ago by: <pedersen

Open Source on OpenVMS Needs HELP I will be quite honest, neither John nor I have had much energy to apply to the effort we are currently involved with of the past few months. The development of the gnuLIB Assist library which we believe w

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days 1 Hour ago by: chris

But are they software engineers ?. Different requirements apply, for example apps programming, web programming and embedded real time. No argument about that, but no doubt many business apps have been written in C in the past. C is stil

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days 1 Hour ago by: Dave Froble

I'm just wondering how many VMS uses actually need the 64 bit addressing? At least Basic, and perhaps other languages, were never modified to take advantage of 64 bit addressing. Sure, there can be some uses that have such a requireme

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days 2 Hours ago by: Craig A. Berry

Unless your C program is using getopt, something from the exec family, or anything else that deals with the argv and environ arrays, some (but not all) of which can be mitigated by further specifying /POINTER_SIZE=LONG=ARGV. Or if you h

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 7 Days 2 Hours ago by: Stephen Hoffman

It's also not what is meant by a 64-bit application on other platforms. Correct. It refers to both code and data. Code which is inaccessible to 32-bit addresses, so don't try to pass a function pointer to that code.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days 2 Hours ago by: Arne_Vajhøj

With an unusual definition of "pure 64 bit" meaning all pointers being 64 bit. You can switch to 64 bit pointers using a compile switch for some languages (C, Fortran). Whether source code changes are necessary for API reasons must dep

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Arne_Vajhøj

It is not what is meant by 32 bit application on other platforms. That does not relate to where the code is. I thought they had started moving code up to P2. And data can be in P2 with some extra work. Stack may actually be the bigg

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Stephen Hoffman

Other than that the default compilation and default link on OpenVMS Alpha and OpenVMS I64 produces apps using 32-bit sign-extended pointers, and necessities using 32-bit ABIs and APIs, sure. Other than that those sign-extended 32-bit

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: JKB

Right. But today, 'im trying to install an HPE VMS with a license given by HP. Best regards, JKB

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Arne_Vajhøj

I do not disagree with that. But even with this issue are STL string/wstring way better than char[] and wchar_t[]. Arne

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Arne_Vajhøj

They need people able to read C and people able to write in the new language. That could be a problem with Pascal and Basic. But you will find more Java and Python programmers than C programmers today. And probably around the same num

Re: Latest graphics drivers for Windows on Itanium (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Stephen Hoffman

David Turner at Island has Radeon 7000 and Radeon 7500 PCI cards available. https://www.islandco.com/hp-parts/hp-integrity-graphics-cards

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Arne_Vajhøj

There are no such thing as a 32 bit application on Alpha, Itanium or x86-64 - applications are all 64 bit (in the meaning of 64 bit application used on other platforms). But that 64 bit application may use: - all 32 bit pointers - all 64

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 7 Days 3 Hours ago by: Stephen Hoffman

P0/P1/S0/S1 are the address ranges available via 32-bit sign-extended pointers. Hardware uses 64-bit virtual addresses throughout. APIs and ABIs use a mixture of 32- and 64-bit pointers. 32-bit pointers are sign-extended to 64-bit.

Re: Latest graphics drivers for Windows on Itanium (thread)

comp.os.vms

Posted: 7 Days 4 Hours ago by: Kurt Stine

I actually purchased my zx2000 from UnixHQ, they're a great company. I guess cheap is more of a relative term with these things. I was able to find those and an extra Nvidia driver (with Geforce 5 support) on the HPE FTP, but like you

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 7 Days 5 Hours ago by: Phillip Helbig (undr

In article <6283cf2f$0$3578$426a74cc@news.free.fr>, JKB <JKB@hilbert.invalid> writes: Probably not relevant to your problem, but the test might be of limited value since a VSI license works only with VSI VMS and an HPE license works on

Oracle really does owe HPE 3 billion USD...

comp.os.vms

Posted: 7 Days 6 Hours ago by: Simon Clubley

https://www.theregister.com/2022/05/17/hp_oracle_supreme_court/ Oracle final attempt to avoid paying HPE 3 billion USD for dropping Itanium support has failed. Simon.

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 7 Days 6 Hours ago by: Volker Halle

JKB, $ HELP/MESS WRGARCH is very clear. There are only 4 possible architecutres for OpenVMS: VAX, Alpha. IA64 and now x86-64 Try $ write sys$output f$getsyi("ARCH_NAME") - it should say: Alpha on an axpbox What does $ LICENSE/LIST/FULL

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 7 Days 6 Hours ago by: Simon Clubley

Are you by any chance using a broken version of axpbox ? What answers do you get if you try the following: $ write sys$output f$getsyi("arch_name") Alpha $ write sys$output f$getsyi("arch_type") 2 Simon.

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 7 Days 6 Hours ago by: Simon Clubley

Wouldn't that cause a licence units error instead ? Simon.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 7 Days 6 Hours ago by: Simon Clubley

There is no such thing as a pure 64-bit program on VMS. Unfortunately. On 64-bit VMS, all existing programs use 32-bit pointers and APIs with 32-bit pointers. If you are prepared to modify your source code, you can also use 64-bit pointe

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 7 Days 6 Hours ago by: JKB

ES40 with only one CPU. But if I remember, I have used this kind of license on my AS800 and a real ES40 (4*500 MHz). Regards, JKB

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this architecture (thread)

comp.os.vms

Posted: 7 Days 7 Hours ago by: abrsvc

What type of Alpha is the AXPBOX emulating? IRRC it is for an ES40 which may not be supported with the hobbyist license. The license was restricted to "personal" machines and not the larger ones. That may be the reason for the unsuppor

Re: %LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this (thread)

comp.os.vms

Posted: 7 Days 7 Hours ago by: JKB

Of course, my hobbyist license is expired, but to test, I have set VMS date _before_ license expiration date. JKB

%LICENSE-W-WRGARCH, OPENVMS-ALPHA license is not valid on this

comp.os.vms

Posted: 7 Days 7 Hours ago by: JKB

Hello, I'm trying to install OpenVMS 8.4 (HP) on axpbox. Of course, I have a recent license issued by HPE (hobbyist). Before asking VSI a hobbyist license, I would test with my old hobbyist license. OVMS is now installed (8.4) and

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 7 Days 9 Hours ago by: chris

Still trying to disambiguate this in terms of what happens with 32 bit code. You mention P0/P1/S0/S1 above, so are these segments and does 32 bit code reside in one of them ?. As I said earlier, if you have a 32 bit app, but a 64 bit (o

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days 11 Hours ago by: Simon Clubley

True, but unfortunately that's somewhat compromised by the fact the default indexing operator in C++ is not bounds checked. It would have been better if [] was the bounds checked operator and ..at() was the non-bounds checked alternative

Re: SSL V3 (thread)

comp.os.vms

Posted: 7 Days 12 Hours ago by: Mark Daniel

Quoting from the github thread https://github.com/openssl/openssl/issues/16552 **** NO CHANGE IN BEHAVIOUR OVER THREE ITERATIONS AND EIGHT MONTHS ***** $ mcr []sesola3 OpenSSL 1.1.1n 15 Mar 2022 value: 1 ELAPSED: 0 00:00:00.23 CPU: 0:0

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 7 Days 12 Hours ago by: chris

But most important of all, that sort of code refactoring needs people fluent in both the original and substitute languages. Since C is the most widely used language. might make sense to stick with it. Recipe for disaster to choose a subs

Re: Latest graphics drivers for Windows on Itanium (thread)

comp.os.vms

Posted: 7 Days 13 Hours ago by: John Dallman

Don't expect to find anything newer than about 2005. HP abandoned the idea of Itanium workstations around then, and treated Itanium as a server platform from then on. The last version of Windows to support Itanium was Server 2008 R2, but

Re: Latest graphics drivers for Windows on Itanium (thread)

comp.os.vms

Posted: 8 Days ago by: Stephen Hoffman

Alas, the comp.os.vms Usenet newsgroup is not usually discussing Microsoft Windows technical support, or Windows on Itanium, which is at the core of this question. DuckDuckGo finds this spec sheet: https://unixhq.com/websgt/hp_zx2000

Latest graphics drivers for Windows on Itanium

comp.os.vms

Posted: 8 Days 1 Hour ago by: Kurt Stine

I know this is different than the point of this group, but it's also the only group I've found that actually knows about Itanium servers/workstations. I recently was able to purchase a ZX2000 workstation. I am now trying to find the latest

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 2 Hours ago by: Stephen Hoffman

ps: String handling is vastly better in C++ than in C. And any reasonable C refactor would necessarily want to look at data security and related.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 2 Hours ago by: Stephen Hoffman

If willing to and funded to rewrite rather than to refactor into C99, or into C11, or (probably, nowadays) into C17 with an eye toward C2x, sure, the implementation choices do expand. Both the choices of language, and the platform. A

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 8 Days 3 Hours ago by: John Dallman

This is not done in the same way as more conventional 64-bit operating systems run 32-code. The VMS APIs were all originally defined as 32-bit, naturally, but they were defined in terms of absolute sizes, not in terms of the sizes of l

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 4 Hours ago by: Arne_Vajhøj

I agree with the advice to get rid of any code requiring /STANDARD=VAXC. But I think those with the problem should consider whether rewriting to standard C99 is the right choice or maybe go for another language. If it is a device drive

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 4 Hours ago by: Stephen Hoffman

Compatibility is always a trade-off, and the complexities inherent in compatibility inevitably accrete. (And you can't churn APIs and tools too quickly, as the lack of compatibility means few or none will want to continue to develop f

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 4 Hours ago by: Stephen Hoffman

If working with or updating old K&R C code, simply finding that compiler switch usually means added work remediating the issues reported by newer C compilers and newer C standards. If that remediation work doesn't happen, the new work

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 4 Hours ago by: Arne_Vajhøj

With JNI the glue is done in C and it is easy to make mistakes in C. Doing the glue in C may have made sense in the mid 90's but no longer. And the new foreign function mechanism (that will hopefully be final in Java 20 or 21) has moved t

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Arne_Vajhøj

Everything is in the same 64 bit address space. It is just that some things can be addressed with 32 bit pointers and other things cannot. Demo: $ type ptrfun.c #include <stdio.h> #include <stdlib.h> #pragma pointer_size save #pragma

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Simon Clubley

_NO_ argument from me on that one. :-) You are talking to the person who enables all warnings and likes to turn warnings into errors using the appropriate options if possible. :-) Simon.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Simon Clubley

The VMS 64-bit design comes across as a technical debt situation where, given the nature of VMS application code, the "easier" approach was taken initially at the expense of long-term maintenance and additional coding work to deal with th

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: John Reagan

It is just another setting in the C frontend, so yes, it is there on x86. However, it hides SOOOO MANY errors and bad programming that I strongly suggest people stop using it everywhere.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Stephen Hoffman

Zig has (some) support for ARMv7a, and ties into C quite well. ARMv7a support and x86-32 support is available in the most recent 0.9.1 version, though is not presently available in Master. For porting, Zig is self-hosting, though LLVM

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Simon Clubley

The main problem with JNI is when you have to write the code manually when interfacing Java with C because it's way too easy to make mistakes. If the COBOL compiler is automatically generating the JNI interface code at both ends, then th

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 5 Hours ago by: Simon Clubley

I'm not sure, but isn't VSI continuing to support /standard=vaxc on the GEM-based C compiler (not the native LLVM clang compiler) for x86-64 ? Simon.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 8 Days 6 Hours ago by: Simon Clubley

:-) That's because I know exactly what I want from a programming language and these days, it seems like most of the time you are using the least-worst option or the most viable option instead of the best option. (Most viable option does

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 6 Hours ago by: Stephen Hoffman

I try. 😉 Though I do well recall a brace of dapper-jumpsuit-over-dapper-three-piece-suit-wearing technicians with their ever-dapper briefcases yelling at each other in the server room. And escorting the customer expectations manag

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 8 Days 6 Hours ago by: Simon Clubley

Hmm, the story of Darmok _is_ a classic. :-) Simon.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 8 Days 6 Hours ago by: Simon Clubley

Thank you for the update Rob. For the benefit of those thinking about writing a VMS device driver, including a more complex example would be very helpful for x86-64. The examples I had in mind were the USB drivers and associated code.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 6 Hours ago by: Stephen Hoffman

Existing and unmodified 32-bit user apps—apps expecting P0/P1/S0/S1 virtual address references—can't receive 64-bit descriptors and 64-bit P2 and S2 virtual addresses from other user APIs and from other third-party APIs and from s

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 7 Hours ago by: Jake Hamby

You're forgetting about IBM z/OS. It's the only OS I'm aware of that has chosen an even more painful hybrid addressing path than OpenVMS. :) They started with a 24-bit addressing mode, then in the 1990s expanded to 31 bits (not 32), with

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 7 Hours ago by: Jake Hamby

I forgot to mention a clever quirk of the OpenVMS calling standard that surprised me when I discovered it: all architectures pass the argument count and argument types in a register (that points to memory on VAX) on function calls, so the

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 7 Hours ago by: Jake Hamby

I think the key to understanding how VMS handles 64-bit space internally is to read about 64-bit descriptors and the new routines for manipulating them (Programming Concepts Manual, Vol I: Part IV. Appendixes: Macros and Examples of 64-Bi

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 8 Days 7 Hours ago by: Jake Hamby

While reading Hunter Goatley's explanation of the VMS memory map from an old article on how to write privileged code (https://hunter.goatley.com/writing-vms-privileged-code/part-i-the-fundamentals-part-1/), I realized that the size of P0

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 8 Days 8 Hours ago by: chris

I can see why there is a need for 32 bit addressing for legacy reasons. If app code is 32 bit, it implies that VMS has some internal 32 bit space reserved within the 64 bit total for that, probably via run time libraries which either outp

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 9 Hours ago by: Arne_Vajhøj

Yes. VEST : VAX -> Alpha AEST : Alpha -> Itanium if Itanium -> x86-64 existed then I assume it would have been called IEST. But I am not super surprised that it doesn't exist. Arne

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 9 Hours ago by: Jan-Erik_Söderholm

If that refers to a IA64 to x86-64 binary translator, then I think that VSI has said that such tool will not be available. Or even exist at all, I guess.

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 11 Hours ago by: Arne_Vajhøj

OK. Some liked them. BTW, I have not heard about an IEST - is that because such does not exist? Arne

Re: a new "rendez-vous autour de VMS" <<< with english part (thread)

comp.os.vms

Posted: 8 Days 11 Hours ago by: Serge General

Key Advantages of ChangeNOW Crypto Exchange https://changenow.io/premium : - Easy-to-use, seamless exchange of cryptocurrencies - Support for almost 400 assets https://changenow.io/currencies - A quick and easy way to stake and profit - A

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 8 Days 13 Hours ago by: Johnny Billquist

I think you missed that in your original post you said you tried to clear 6G. :-) That was more what my response targeted. The part about missing the last few bytes do sound like a bug, but I can't really tell if it actually is there o

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 8 Days 16 Hours ago by: Paul Hardy

Oh we did. VEST was an amazing facility, and let us extend the life of a particular software suite by decades. — Paul Hardy

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 9 Days ago by: Arne_Vajhøj

VMS did have VEST and AEST. I don't think people liked them. Linux got aio, epoll, libevent etc.. Maybe it is more of a bolt-on than native, but it is there and that is what matters. I would try and sell VMS as being lean. Linux is ge

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 9 Days ago by: Stephen Hoffman

Far too often, OpenVMS has 32-bit virtual addressing "to play with". As I've mentioned in other threads: go try this stuff. Write a complete 64-bit app. Use a mix of some of the available languages. Try using BASIC as part of your te

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days ago by: Arne_Vajhøj

I don't like the term segmented as opposed to flat to describe the VMS memory either. If you use a language that supports 64 bit pointers and you enable it then your program is accessing a 64 bit flat address space. But there are a gazi

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days ago by: Arne_Vajhøj

But a fun hypothetical question: Let us assume: * VSI got VMS running on Superdome Flex * no VMS customers had any specific hardware requirements * all VMS customers were happy with a PaaS (time sharing) solution (not the case, but l

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 9 Days ago by: chris

I think that sort of info is what I was driving at. So used to flat address spaces these days, it's difficult to imagine anything else, but it does look like VMS has plenty of space to play with, even if segmented in some way... Chris

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 9 Days 3 Hours ago by: Stephen Hoffman

The word "potentially" is doing a whole lot of work, there. Once y'all use a flat 64-bit address space and APIs, the existing and hybrid memory management compatibility-focused design starts to smell vaguely of TKB. The lack of a cl

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 3 Hours ago by: Arne_Vajhøj

This thing: https://en.wikipedia.org/wiki/Intel_5-level_paging 57 bit = 128 PB But other sources talk about 52 bit and 4 PB (not 4 EB). But that seems to be 4 level with PAE (not to be confused with 32 bit PAE). Maybe we should just c

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 3 Hours ago by: Arne_Vajhøj

Ooops. 4 PB not 4 EB. Thanks. Arne

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 9 Days 3 Hours ago by: Stephen Hoffman

From the post: 48, and 57 bits. 48 is near filled. HPE Superdome Flex presently supports 32 sockets and 48 terabytes. That'd be a stretch for OpenVMS SMP support, and the rest of the system. Any servers approaching the five-level 5

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 4 Hours ago by: John Dallman

That's right, if a little understated. Currently, 48-bit physical addressing is the limit. The current page table format allows for 52-bit, which gives you 4 petabytes. ARM64 likewise goes up to 48-bit physical addressing at present

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 4 Hours ago by: Arne_Vajhøj

The above is all about virtual addresses aka what is seen by a process. Physical memory in a system is a completely different issue. VAX had a hard architectural limit that was reached. I believe that on Alpha, Itanium and x86-64 it is

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 9 Days 6 Hours ago by: chris

Thanks for the extensive reply, though still not quite sure what the limits of usable memory are. Last VNS here was 5.4 / Vax and istr, the overall limit was 4Gb, split nto 2 x 2 GB sections... Chris

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 9 Days 6 Hours ago by: chris

The question still remains, what are the limits to memory size that can be seen at boot time and fully used by VMS ?... Chris

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 9 Days 6 Hours ago by: chris

Of course it would. Much simpler architecture, small scale integration logic devices, less memory and complexity in the software as well. All contributes to reliability. From what a dealer told me some years ago, pdp11/05 series were st

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 9 Days 7 Hours ago by: Stephen Hoffman

That's prolly related to much of the US nuclear power industry and regulatory oversight being so utterly obdurate. No new designs approved and online in how many years? There are a few positive signs, with one SMR design only recently

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 10 Hours ago by: Arne_Vajhøj

I think it is muddling the matters when people talk about 32 vs 64 bit applications and even worse 32 vs 64 bit mode. VMS does not have any of that. Unlike Windows, Linux, macOS etc.. VMS has 32 and 64 bit pointers. And the granularit

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 9 Days 10 Hours ago by: Arne_Vajhøj

I believe they are very actual. VAX, Alpha, Itanium, x86-64. Alpha, Itanium and x86-64 are 64 bit machines. But that does not change P0 and P1 space in VMS. VMS design. Due to VAX compatibility decisions made 30 years ago. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 9 Days 12 Hours ago by: VAXman-

That really blows! <rolleyes>

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 9 Days 12 Hours ago by: Scott Dorsey

That's terrible! For years the PDP-8e was the standard controls machine for nuclear power applications; the Nuclear Engineering department at Georgia Tech continued teaching PDP-8 assembler well into the early 2000s. Mind you where I wor

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 9 Days 13 Hours ago by: Gérard_Calliet

We have a long way to be able to play with all of our idioms. Perhaps being more classic, using only the authors used on the Internals epigraph chapters? Or just Shakespeare's? We really to get a common langage for the next boot camps :

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 10 Days ago by: Stephen Hoffman

Apologies on any bit-width errors latent in the following. This posting differentiates virtual addressing from physical addressing, and largely ignores discussions around physical addressing including about 48-bit physical addressing

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 10 Days 1 Hour ago by: chris

Those numbers were theoretical, but X86-64 will have hardware memory management capability for more than that. I'm using proliant G8 series for work, as an economical sweet spot from a cost pov, but they are often advertised with 16 to 64

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 10 Days 8 Hours ago by: John Reagan

I didn't take much time (<1 minute) to try to reproduce. I don't have lots of time to track down github sources. If you can send one to me, I'd appreciate it.

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 10 Days 8 Hours ago by: John Reagan

VAX floating isn't related to any pointer/size_t issues. We have VAX floating on the non-C++ compilers. For C++, I'm thinking about writing a C++ class to provide VAX floating support without hacking it into clang. OTS$FILL is in LIBOTS

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 10 Days 9 Hours ago by: Jake Hamby

I'm hoping that a 64-bit time_t would be part of the new ABI mode as well. The current unsigned 32-bit type is yet another portability issue. At least you no longer have to support VAX floating-point in the new modes, so it should hopeful

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 10 Days 9 Hours ago by: Jake Hamby

Strange. It's really easy for me to reproduce, by fiddling with the value of max_clear_bytes on line 525 of memtester.c in my fork of the tree: https://github.com/jhamby/vms-memtester If I call memset() with a value larger than 0xffff000

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 10 Days 9 Hours ago by: Jake Hamby

I think I may have been unclear in my original post. I was able to memset up to 0xffff0000 bytes successfully, but not any higher. I originally tried to loop and fill 0xffffe000 (4GB minus one 8K page), and then discovered that memtester

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 10 Days 21 Hours ago by: Richard Maher

Don't worry, when we need to stock up on white flags we know where to go. That's him. What do you me "too" :-)

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 10 Days 21 Hours ago by: Jake Hamby

VMS definitely doesn't have as good of a track record as z/OS, where they've stayed binary backwards compatible to assembly language written in the mid-1960s. They have products like a COBOL optimizer that can take customers' code that wa

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 10 Days 22 Hours ago by: Jake Hamby

I'd hope that the APIs haven't changed too much between Alpha and newer systems. They're all little-endian and 64-bit, after all. One of my Twitter friends who likes collecting 1990's PCs has been writing Voodoo2 PCI drivers to port Glid

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 10 Days 22 Hours ago by: Arne_Vajhøj

You are not an easy customer to sell a programming language to. :-) Rust and Go is what is new with some serious momentum/backing. If you are willing to go for more exotic options, then maybe Hare will fit your requirements. Arne

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 3 Hours ago by: Stephen Hoffman

It's a quite a good and well-researched book. But it's getting a little old. The errata for Margie and Lenny's driver book is fairly extensive too, based on the number of sticky-notes my copy has accumulated over the years. VSI hasn'

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 3 Hours ago by: Stephen Hoffman

Not what I would assume. Most likely a reference to a Yale-educated US politician known for certain mispronunciations and for a premature accomplishment. Your own and earnestly erudite postings can sometimes be just as confusing to t

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 3 Hours ago by: Robert A. Brooks

Lenny's book is still quite relevant today. The specific thing that it documents is the non-MACRO-32 interfaces to device driver and other executive routines. Those interfaces have not changed. What *has* changed for X86_64 is th

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 11 Days 5 Hours ago by: Johnny Billquist

I would have expected that you could run this even if you have way less ram. That's what virtual memory and demand paging is there for. Sound like it might behaving exactly as it should. The size argument to memset is a size_t. If size

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 6 Hours ago by: Simon Clubley

Yes, I remember that (and I have my own personal copy that I bought from a bookshop). I was talking about the online documentation because that's where John was looking above. These days, what do support contract people get in their Ita

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 8 Hours ago by: chris

With an open source OS, Linux, FreeBSD etc, the system probes the hardware at boot time, against a background of probably thousands of different hardware interface vendors and manufacturers. All that knowledge is effectively shared betwee

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 10 Hours ago by: Robert A. Brooks

If you were a DEC customer paying for VMS MDDS (media and documentation distribution service), then you got Lenny Szubowicz's driver book along with the full documentation set.

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters (thread)

comp.os.vms

Posted: 11 Days 11 Hours ago by: Simon Clubley

From that article: |However, we want to stress that Go cannot be considered a replacement for C |as there are many places where C is and likely will be needed, such as in |the development of real time operating systems or device drivers.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 11 Hours ago by: Simon Clubley

The last public VMS device driver manual I am aware of is the one for Alpha VMS. It is a book in its own right (just like the old Digital Press books) and it is not a part of the VMS documentation set. However, writing a device driver fo

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 12 Hours ago by: Jean-Baptiste Boric

Linux mostly runs with kernel-mode device drivers in-tree, maintained alongside the kernel. Some hardware vendors who can't be bothered to upstream their stuff ship vendor kernels instead, which are (usually poorly maintained) forks of the

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 11 Days 13 Hours ago by: VAXman-

But, but, but, ... C!

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 15 Hours ago by: Gérard_Calliet

American humour? When something dangerous exists, just ignore it. I thought it was just in australia where they believe in ostrich politics. (french humour)

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 11 Days 16 Hours ago by: Andrew Brehm

I wonder if "support" means developing some paravirtualisation drivers, aka vmtools. If OpenVMS VMs cannot be shut down properly by the hypervisor but requires timed or manual work on the OS, it will be difficult to sell this to custome

Re: SEARCH '' (thread)

comp.os.vms

Posted: 11 Days 18 Hours ago by: Tad Winters

Just for fun. $ QUOTES[0,16] = 10023 $ SEARCH <file> &QUOTES

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 18 Hours ago by: Gérard_Calliet

Sorry, I was thinking you said there are not any use cases for bare metal. One day.

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 11 Days 21 Hours ago by: John Reagan

There is so much bad code out there that uses size_t or ptrdiff_t instead of intptr_t that I'm getting tired of even trying to justify it anymore.

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 11 Days 21 Hours ago by: John Reagan

Yeah, _memset64 zero-extends the size argument before calling OTS$FILL (which handles 64-bit lengths just fine). As you note, it is all related to size_t being 32-bits and assuming that no single variable can be larger than that. So mems

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 11 Days 21 Hours ago by: Richard Maher

Just be in the UK when the govt privatize the railways and needs someone to give the rolling stock to. You and your mates set up a company with just GBP15K each and then all the new companies have to lease it off you at a huge profit.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 11 Days 21 Hours ago by: Richard Maher

Or just do an Oracle and don't support (insure against) nuclear reactors. And to our American friends that's not pronounced Knewklar

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit (thread)

comp.os.vms

Posted: 11 Days 23 Hours ago by: Arne_Vajhøj

https://stackoverflow.blog/2022/04/04/comparing-go-vs-c-in-embedded-applications/ Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 11 Days 23 Hours ago by: Arne_Vajhøj

I don't believe that. Why do you think there is an entire industry around moving Cobol programs from mainframe to newer platforms? Because companies can't change file names and recompile?? Arne

Re: Can't memset() more than 4GB - 64KB (thread)

comp.os.vms

Posted: 12 Days 1 Hour ago by: Craig A. Berry

It may eventually be possible to have a compiler mode that changes the model from LLP64, as it is now, to LP64 or ILP64, at least for the clang-based compilers.[1] I'm not actually sure that LLP64 even considers the possibility that size

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 12 Days 3 Hours ago by: Jan-Erik_Söderholm

But then, just use one of the supported "bare metal" solutions. It has never been said that bare metel would not be supported *at all*, has it? The roadmap still has "full support for HPE DL380" for 9.2-x.

Can't memset() more than 4GB - 64KB

comp.os.vms

Posted: 12 Days 3 Hours ago by: Jake Hamby

https://github.com/jhamby/vms-memtester/ Apart from the expected cursing that size_t is only 32 bits, and after setting my WSMAX, WSQUOTA, and WSEXTENT to sufficiently high values, I discovered that the version of memset() in OpenVMS V8.

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 12 Days 3 Hours ago by: Gérard_Calliet

Do you live near a nuclear plant? Do you think you would be pleased to know the OS used to control it has part of it on the cloud? Do you take underground? What about being somewhere in it and there is just a subtle problem somewhere in

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 12 Days 3 Hours ago by: Jake Hamby

That's right. One of the drawbacks of Itanium (and Alpha) is that there's only one provider of hypervisors, and no cloud VM providers. The only limitation I can see now with using VMS on supported hypervisors is that they don't yet suppor

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 12 Days 3 Hours ago by: Stephen Hoffman

Most hardware vendor folks that want to sell hardware will perform the hardware qualification themselves for Microsoft Windows, and get onto the Microsoft HCL. Where this gets more interesting for third-parties are hardware or firmwa

Re: The hardware support problem for x86 (thread)

comp.os.vms

Posted: 12 Days 4 Hours ago by: Jan-Erik_Söderholm

I thought that VSI said that the increast focus on VM environments is due to customer demands. As I understand, the major part of VSI income comes from customers where running in a VM is the prefered solution. I really can't see the nee

The hardware support problem for x86

comp.os.vms

Posted: 12 Days 4 Hours ago by: John Dallman

Listening to the latest webinar, it was mentioned that a common question from customers was about support of specific hardware. At that point, I realised that the variety of x86 server hardware currently available probably exceeds the total

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 6 Hours ago by: Simon Clubley

Oh, but that is most certainly _not_ the case. :-) Old rolling stock has ongoing maintenance and safety inspection costs. You also have additional costs to consider as external factors cause a change in the operating conditions of the o

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 12 Days 8 Hours ago by: Ian Miller

VSI Webinar 11 May x86 port update now on YouTube https://youtu.be/eH8gAjoOkXI

Re: Unique Features (was Re: VMS article in The Register) (thread)

comp.os.vms

Posted: 12 Days 8 Hours ago by: Stephen Hoffman

Graphics controllers in general? No. ECC is omitted in most (all?) low-end and embedded graphics, same as ECC is largely omitted by Intel below Xeon. CUDA and related hardware aimed at HPC do offer ECC. And whether the offloading goes

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 12 Days 8 Hours ago by: Gérard_Calliet

I think it's because Adacore had to maintain Ada on Itanium. Not on Alpha where there were Dec Ada, as you know. Unfortunitly, they stopped the support in 2015, and didn't publish for VMS after that. So we don't have anything good on ve

Re: Why Linux ?, was: Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 9 Hours ago by: Bill Gunshannon

Fantasy world. I recently learned of an application that stopped working after 5.4-5.5. Knowing the application I am sure the response here would be who cares. But the fact is it did stop working. But the only thing that makes them u

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 9 Hours ago by: Bill Gunshannon

Sorry, makes no sense. Old rolling stock costs nothing. Running any mainframe costs a lot. 1,2 and 3 can apply. #4 is just as much a threat for OS2200 as it is for VMS and any other legacy system. (Well, except probably for IBM. :

Why Linux ?, was: Re: VMS article in The Register

comp.os.vms

Posted: 12 Days 10 Hours ago by: Simon Clubley

Why Linux over VMS ? Far stronger security features than VMS as it currently exists. A vast range of applications available, including being _the_ leading platform for a range of applications these days. An enormous pool of trained peo

Re: Unique Features (was Re: VMS article in The Register) (thread)

comp.os.vms

Posted: 12 Days 11 Hours ago by: Simon Clubley

Do graphics cards in general have ECC memory ? Some appear to do so, but I can't tell if the majority of them do. Simon.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 11 Hours ago by: Simon Clubley

The reason could be something as simple as the reason why (for example) train companies continue to run decades-old rolling stock alongside more modern rolling stock. Ie: it works, it's reliable, it's a known quantity and it's in no dang

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 12 Days 11 Hours ago by: Simon Clubley

And you were fortunate in that the state of Itanium VMS in the FSF sources appeared to be in a far better state than those for Alpha VMS appeared to be. Unfortunately, there's no such thing as an Itanium full system emulator or that's wh

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 12 Hours ago by: Bill Gunshannon

At least in the case of COBOL, with only minor changes to allow for file naming conventions, it actually is. And with Fortran even more so. Which brings us back to the question why are so many Univac customers still with Unisys? Just

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 12 Days 12 Hours ago by: Gérard_Calliet

indeed

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 14 Hours ago by: Louis Krupp

It's been many years since I've done anything with DMSII, but as I recall, it was possible to use it to implement a relational database with decent performance. It was also possible to create hierarchical databases (and maybe even netw

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 16 Hours ago by: David Wade

IBM of course have the answer to that. Just as in the days of the NT only Alpha boxes, IBM have differential pricing for CPUs for running Z/OS and CPUs running Linux. They are known as "Integrated Facility for Linux" or IFL CPUs. They

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 22 Hours ago by: Arne_Vajhøj

Just recompiling is probably not the case for most. Otherwise they probably would have migrated. Wanting to update the system to stay competitive is quite common for private businesses. Government systems do not need to worry about th

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Bill Gunshannon

Mainframes cost money. People with scarce talents cost money. Everything costs money. One has to look at which costs more money. If the major part of the move involves little more than recompiling a COBOL program where are all these n

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Bill Gunshannon

The hardware alone would cost a fraction of the current amount. The salaries of people working with common systems tend to run a lot lower than the salaries of people with skillsets that are rare. Again, I am talking here about a system

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Bill Gunshannon

The advantage to what staying or moving? The advantage to moving in some cases is reduction of cost. Well, using the example of the programs I worked on, the access to the data was done with embedded SELECT statements. Not a lot of di

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Arne_Vajhøj

The migration effort itself (ensure that the functionality is documented, actual development work, test, project management) cost money. It is almost a given that the new system will have way more bugs the first few years than the old sy

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Arne_Vajhøj

You can get APL almost anywhere. https://github.com/dzaima/APL should be a pretty good APL implementation and only requires Java 8+ to run. Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 12 Days 23 Hours ago by: Dave Froble

Money? Risk? If all that is desired is to move from X to Y, there can be significant cost and risk. For basically a sideways move, and most likely the loss of some capabilities. If the application(s) are working just fine, then why

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days ago by: Dave Froble

There is the question, what is the advantage. My experience is that using SQL means significant changes in the basic design of programs that do a lot of data access. The question is, why do so, if the current application is working we

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days ago by: Arne_Vajhøj

Given that companies are spending two digit and three digit millions of dollars on projects to migrate off mainframe, then I assume that the numbers are not in favor of the mainframe. A z16 has max 200 core and max 40 TB. 20 mid size s

Re: Unique Features (was Re: VMS article in The Register) (thread)

comp.os.vms

Posted: 13 Days 2 Hours ago by: Grant Taylor

The multi-host aspect is the key point that I'm referencing. I'm not aware of any other software RAID (especially at the block level) that is multi-host aware. DRBD /might/ approach this. However I'm not aware of any DRBD implementa

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 2 Hours ago by: Bill Gunshannon

Given a reason to do so I could point out piles of reasons to move. That;s why I said it would be valuable to know just what makes them stay. In one case, I know the reason. But there are a number of others where the reason is very uncl

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 2 Hours ago by: Bill Gunshannon

Depends on what you mean by compatible. DMS11 predates the plethora of SQL based databases so the syntax is a little different. But there is nothing that DMS11 does that modern DBs can't do. Yes, some modification of the source for tha

Re: Unique Features (was Re: VMS article in The Register) (thread)

comp.os.vms

Posted: 13 Days 3 Hours ago by: Stephen Hoffman

Unfamiliar with mainframes' features here, but more than a few vendors have tried hardware clustering. And failed. StorageTech IIRC tried that on then VAX/VMS back in the 1980s, and failed hard. The OS has the necessary context, and n

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 3 Hours ago by: Arne_Vajhøj

I think very few people claim that x86-64 is a great CPU architecture. But for various reasons it got the volume. And with the cost structure in the CPU market then the high volume CPU wins. The main advantage of Linux is that for the

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 4 Hours ago by: Dave Froble

Perhaps they do not see any advantages worth making any such moves. If VMS had not lost it's "native hardware", perhaps it would also be treated similar. Losing first VAX, then Alpha, and even itanic could be a turn off for some peopl

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 4 Hours ago by: Dave Froble

One might claim inertia, but then, that would also imply that x86 is better. I don't think x86 should get that much of assumed advantage. But perhaps that's just me. In many ways they are very unalike. More than just the terminolo

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 4 Hours ago by: Arne_Vajhøj

MySQL could probably handle the data size. Facebook use MySQL to handle double digit PB of data. But it will require changes to application. From what I can read from https://en.wikipedia.org/wiki/Unisys_DMSII then it is not in nay way c

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 4 Hours ago by: Bill Gunshannon

Once again you are tying to apply VMS logic to someone else. I am personally aware of two very large ISes that run on OS2200. Both of them are over 40 years old and run pretty much as they have from the beginning. One I know is written

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 4 Hours ago by: Arne_Vajhøj

Not necessarily. There can be a lot of small devils in the details: * use of platform specific extensions to the language * pieces of assembler. * assumptions about file system. * assumptions about endianess * assumptions about bit size

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 5 Hours ago by: Grant Taylor

It seems as if many of these platform specific advantage are largely unknown outside of the platform. As such, application designers have often found different ways to achieve the desired effect using completely different functionalit

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 5 Hours ago by: Grant Taylor

I don't buy that statement nearly as much as I once did. Yes, languages exist on many, if not most, platforms. However there is more to programs than just the languages themselves. There are other things that the platform provides wh

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 13 Days 5 Hours ago by: Arne_Vajhøj

I know it is a big project. I dabbled a little bit into GCC on VMS around version 1.somethingaround40. I don't think everything has to be same as VSI. But for compilers specifically I think they should generate code compatible with VS

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 5 Hours ago by: Bill Gunshannon

If that were the case OS2200 never would have come about. Most of what they run is HLL. COBOL (still a lot of 68) and Fortran. Any of which could be easily ported to Linux or even Windows. There has to be a reason so many people people

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 13 Days 5 Hours ago by: Gérard_Calliet

HP and VSI didn't do anything on Ada Itanium. All was done by Adacore. And I have just rebuilt the work done by Adacore from sources on FSF. Quite same thing taking the work done by Adacore on gnat-llvm and rebuilting it on VMS/x86. Onl

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 13 Days 7 Hours ago by: abrsvc

If you have a location for that tool, great. IF not no big deal. The problem was solved by renaming it out of the way and no other issues have arisen since. This query was more of a "can I find out what happened" rather than a search f

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: Volker Halle

Dan, there is (was ?) the internal QMALLET utility, which could be used to look at the QMAN journal file with formatted output. Regards, Volker.

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: Grant Taylor

They could switch to Raspberry Pis too. But it turns into a numbers game. Cost of system(s) / cost of operations / installation space / power / cooling / etc. I don't know how many high end x86 systems you'll need to run 100k Linux

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: John Dallman

VMS may not have been different enough from newer platforms to make transitions painful for lots of companies. Alpha, while excellent, wasn't all that different from other RISC architectures once they were extended to 64-bit. VMS termi

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: Arne_Vajhøj

If they only need Linux then they could save money by switching to x86-64. You could not run that on a single x86-64 system, but you could on multiple x86-64 systems, which would be a lot cheaper than that mainframe. z/TPF for those t

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: HCorte

Thanks @VaxMan and @Arne for the examples, CHARACTER*256 MSG INTEGER*4 ERR_NUM INTEGER*4 LIB$SYS_GETMSG CALL MVBITS( SIGARGS(2), 0, 32, ERR_NUM, 0) CALL LIB$SYS_GETMSG(ERR_NUM,MSGLEN,MSG) tried reading only bit 3 to 15 of SIGARGS

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 8 Hours ago by: Robert A. Brooks

Similar to how Teracloud/VSI acquired the development rights to VMS from HP, Teracloud/21st Century Software acquired the development rights to VSE from IBM https://www.21stcenturysoftware.com/21st-century-software-announces-vsen-v

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 9 Hours ago by: Grant Taylor

Traditional mainframe OSs are almost certainly why the original mainframe was originally installed at an institution. But that is historic and does not account for why the mainframe has been refreshed over the years. When I was aroun

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 13 Days 9 Hours ago by: Stephen Hoffman

Something to ponder... What was posted was a "hey, is there any reason the queue manager might fill the journal over the entire lifetime of OpenVMS and VAX/VMS and across all versions, and would you mind researching the various patche

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 11 Hours ago by: Arne_Vajhøj

True. But I suspect that z/OS is the reason the mainframe is there and the Linux instances got added to provide supporting services. I expect very few to buy a mainframe to only run Linux - does not make sense financially. z/VSE? I th

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 11 Hours ago by: Bill Gunshannon

OS2200 is alive and well. Like zOS backwards compatibility has been maintained at least as far back as Univac 1100 EXEC8. They also have a program that let's you run it on a PC kinda like what VSI does with the education program. There

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 11 Hours ago by: Arne_Vajhøj

I got the impression that Unisys was mostly services around industry standard servers today. But then I am not close to the Unisys world, so they may have firm support for OS 2200. So maybe more like HPE NonStop than HPE HP-UX. Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 16 Hours ago by: John Dallman

The manufacturer (Unisys) wants to keep OS 2200 alive, unlike HPE with HP-UX. Since CPU performance was never very high, this is practical via emulation on commodity processors, and that's how it's been done since 2015. <https://www.un

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 19 Hours ago by: Grant Taylor

There is also a separation of z/OS and the platform that it runs on. Linux is also quite popular on the mainframe platform. I speculate that there is a 10 or even 100 to one ratio between Linux on the mainframe and z/OS on the mainfra

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 22 Hours ago by: Arne_Vajhøj

z/OS got a much larger customer base than VMS so they are far better off, but it is still a platform companies want to migrate off not migrate on. I don't know much about OS 2200 but my feeling is that it is more like the HP-UX state. A

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 22 Hours ago by: Bill Gunshannon

zOS? OS2200? bill

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 13 Days 22 Hours ago by: plugh

Correct. It's for embedded systems. And .. ..

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: Arne_Vajhøj

Yes. But with all due respect for the great work you do then it is not the same as VSI or ACT. Arne

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: Arne_Vajhøj

Rust use heap. That library you link to apparently does not use heap. Arne

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: Arne_Vajhøj

P1 is only 1 GB. Or probably more relevant P1 + P0 is 2 GB as I assume the stack could grow below 0x0000000040000000. Arne

Re: VMS article in The Register (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: Arne_Vajhøj

Of course he has a point. VMS still has some users that like it, but it is not like tens of thousands of new users will show up tomorrow. But the same point could be made for any server OS besides Linux and maybe Windows. VMS has more

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: chris

Well, that gives you 4Gb stack space, which should be enough for most, while ]the 64 bit heap, virtualised of course, should be enough for any real world process. Depending on OS limits, of course... Chri

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 13 Days 23 Hours ago by: plugh

Don't quote me on this, but I'm not entirely sure compiler changes are required. I was starting some research on this a few weeks ago, based on the design of the Rust Core Library https://doc.rust-lang.org/core/ in which there's no hea

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days ago by: Arne_Vajhøj

There is: * a stack P1 that can be accessed via both 32 and 64 bit pointers * a heap P0 that can be accessed via both 32 and 64 bit pointers * a heap P2 that can be accessed only via 64 bit pointers I don't think that P1 and P2 being "d

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 1 Hour ago by: plugh

As I understand the current memory model, the stack is 32 bits, the heap 64.. What impact if any will that have?

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 1 Hour ago by: plugh

Yeah, I did say "storm the castle". I'll pay attention to that disabled checkbox. There used to be monitoring services for such things.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 14 Days 1 Hour ago by: chris

Per Ardua ad Astra :-)...

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 6 Hours ago by: plugh

Per aspera ad astra!

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 6 Hours ago by: Simon Clubley

Well, you would be famous if you pulled off the last sentence... :-) Whether that's "good" or "bad" famous remains to be seen... :-) Simon.

VMS article in The Register

comp.os.vms

Posted: 14 Days 6 Hours ago by: Simon Clubley

General jist is that VMS is available on x86-64, but does anyone care ? https://www.theregister.com/2022/05/10/openvms_92/ Subtext underneath the title from the article: "One of the most battle-tested OSes out there hits commodity kit,

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 6 Hours ago by: plugh

I appreciate the enthusiasm, but it's emulators all the way down. I'm won't do this kind of work in that environment. Quoth the Mickey, "Hey kids, let's port Rust to the PDP/8!" jec

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 6 Hours ago by: Simon Clubley

Once again, as I and others have pointed out yet again just recently, there is a VSI Alpha hobbyist program. It's only the HPE program that is dead. I'm running VSI Alpha VMS just fine on the VSI hobbyist program at home (even if I have

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 6 Hours ago by: plugh

If the hobbyist pgm is dead, I'm not sure how to move this forward. If we can get a few people together, maybe we can storm the castle.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 14 Days 8 Hours ago by: Ian Miller

that sounds like a good idea :-)

errata : all about ada is mine. I confused with my function of (thread)

comp.os.vms

Posted: 14 Days 12 Hours ago by: Gérard_Calliet

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days 12 Hours ago by: VMSgenerations worki

Agreed. A lot of things can be done upgrading the current gcc/ada/itanium cross compiled chain (maintained and used here in France). But it would be a nighmare doing the same for VMS/x86. However, Adacore has a pure OpenSource project u

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days 12 Hours ago by: VMSgenerations worki

Except for who use it and who maintain it :) Yes Adacore killed its support in 2015. Yes VSI cannot do anything until today (no sufficient use cases). But as "the king is dead, long live te king", "VMS is dead, long live VMS",... who k

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 14 Days 15 Hours ago by: Single Stage to Orbi

As another poster explained, the process for that will be considerably simpler as VMS on x86_64 supports ELF and the all the heavy lifting for generating x86_64 object code is already implemented.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days 22 Hours ago by: Bill Gunshannon

I have never seen an APL Compiler. Doesn't mean one never existed, but what Ken Iverson created was an interpreted language. I still have a few versions of APL running around here. It's a fun language to play with and got more use than

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days 23 Hours ago by: Arne_Vajhøj

That I did not even consider. BTW, is APL a compiler or an interpreter? Arne

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 14 Days 23 Hours ago by: Bill Gunshannon

Not to mention APL. :-) bill

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 15 Days ago by: Arne_Vajhøj

I must admit that I consider Ada on VMS as dead (along with PL/I). Arne

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 15 Days 5 Hours ago by: John Dallman

This will be simplified, a bit, by x86-64 using ELF, as opposed to the VAX or Alpha object languages. But that means only parts of the old support need putting back. John

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 15 Days 6 Hours ago by: Simon Clubley

You have clearly never looked deeply into the gcc and binutils internals or you have way more knowledge about gcc internals than I do... :-) I looked at this for Alpha and I eventually gave up, because even with some VMS support still in

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 15 Days 6 Hours ago by: abrsvc

If you read the original posting, there was a "fix" which was to rename the file out of the way so that the startup created a new journal file. I didn't post the version for a reason. I fully researched the version and any patches associ

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 15 Days 6 Hours ago by: Simon Clubley

This is where knowing the exact VMS version is absolutely critical Dan. If it's a modern VMS version, I have no answers, but if it's a really old version (1990s era), then I have personally experienced this. There was a bug in a VMS ver

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 15 Days 8 Hours ago by: Stephen Hoffman

For the SCSNODE mess, that doesn't matter. The queue manager will happily wedge the system startup on a standalone node, if SCSNODE changes. But again, that's seemingly not a factor here. Presumably no run-away batch job submissions?

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 15 Days 8 Hours ago by: abrsvc

This is a single system (no cluster, sorry I should have included that). Space was not the issue as a simple rename of the journal file resolved the problem and things continued with the reboot where it hung before. Without spending too

Re: Queue manager journal file (thread)

comp.os.vms

Posted: 15 Days 8 Hours ago by: Stephen Hoffman

Queue manager hangs arise when storage is insufficient, or when the cluster is incomplete or misconfigured, or when the local SCSNODE host name changes, or when you've encountered a queue manager bug. The SCSNODE hang is probably the

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 15 Days 9 Hours ago by: Ian Miller

A supported ADA compiler for OpenVMS is wanted.

Queue manager journal file

comp.os.vms

Posted: 15 Days 9 Hours ago by: abrsvc

Just had a case where the journal file exploded to over 3Million blocks with no indication of any problems. Restarting the system (for other reasons) brought this to our attention because the queue manager wouldn't start. Renaming the jou

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 15 Days 10 Hours ago by: Single Stage to Orbi

As soon as they make the compilers available, it should be straightforward to port the GCC suite over to the x86_64 platform and that'll include ADA if VSI doesn't port Ada over as well. On another note, I think it'll be interesting to

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 15 Days 11 Hours ago by: Simon Clubley

[Now it's my turn. :-)] Hey, you forgot about Ada! On a more serious note, so did VSI, probably because all the Ada users have probably been forced away from VMS by now... Simon.

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 15 Days 15 Hours ago by: gah4

(snip) From man vfork() on my system: "vfork() can be used to create new processes without fully copying the address space of the old process, which is horrendously inefficient in a paged environment. It is useful when the pur

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 16 Days ago by: Arne_Vajhøj

Oh yes. C++ is needed for a lot of platform type stuff. LLVM, OpenJDK etc.. I was not indicating that C++ was not needed. I was just trying to say that I don't think there are that many VMS C++ custom business applications out there.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 16 Days 4 Hours ago by: John Dallman

A good C++ compiler will be necessary to get ISVs to start supporting VMS. (It's also required for compiling the LLVM backend for native compilers on x86.) John

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 16 Days 4 Hours ago by: Arne_Vajhøj

My guess is that VMS is one of the most diverse platforms when it comes to native languages usage. *nix and Win are almost entirely C and C++. Mainframe has a strong presence of Cobol and PL/I and today probably some C and C++ and maybe

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 16 Days 5 Hours ago by: John Reagan

Yes, all native compilers are planned. I don't expect Pascal to be a challenge once we get the bugs from BLISS and C shaken out. I might have the Moria kit somewhere but it might take a while before I find time to try the cross-compiler

Re: Disk Geometry (was: Re: SIMH disk geometry help required please) (thread)

comp.os.vms

Posted: 16 Days 7 Hours ago by: Stephen Hoffman

Alas, it once did. Until IBM cleverly re-allocated parts of data structures reserved for tapes for disks, and the change got adopted as part of the spec.

Re: Disk Geometry (was: Re: SIMH disk geometry help required please) (thread)

comp.os.vms

Posted: 16 Days 13 Hours ago by: Johnny Billquist

I think you partially missed my point. SCSI-2 itself will either place a limit of roughly 1GB, or else 2TB (unless we go to even bugger sizes). There is no way that SCSI-2 itself would ever have a limit of 8.58GB. Sure, the VMS driver

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 16 Days 22 Hours ago by: Mike K.

So, is native Pascal planned? It would be fun to get something like VMS Moria up and running, which should in theory be possible with Pascal and Macro.. Alternatively, has anybody with access to the current cross-compilers tried to build i

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days ago by: Arne_Vajhøj

I am pretty sure that could be converted to Java running on VMS I64 (and in the future VMS x84-64). VMS Alpha Java 5 may be too old. Java has the basic encryption stuff. Java has the annotation based RESTful web services either JAX-RS ba

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days ago by: Arne_Vajhøj

One question is the definition. I believe most have some intuitive understanding though not necessarily precise definition of what a server is and what a "client" (desktop, tablet, phone) is and what embedded is. Another question is whet

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days 6 Hours ago by: Stephen Hoffman

iCloud Keychain requires an existing iCloud Keychain client be logged into the same Apple ID, and to further explicitly "approve" a newly-added client attempting to access iCloud Keychain, yes. https://support.apple.com/en-us/HT204085

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days 11 Hours ago by: Bill Gunshannon

I guess it depends on your definition of "client device". Some of us run VMS not as a server. Does that make it a "client device"? I am sure there are production environments where VMS is used not as a server but for other tasks. Would

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 17 Days 13 Hours ago by: VAXman-

Nevermind. I checked on EISNER (a newer FORTRAN) and SS$_FISH is there.

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 17 Days 13 Hours ago by: VAXman-

Moreso than cute, it was disturbingly eye-opening! There is no SS$_FISH in the $SSDEF module in FORSYSDEF.TLB.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 17 Days 14 Hours ago by: Single Stage to Orbi

Perfect, that can be used to bootstrap a compilier. it's just a matter of writing something in macro that can be used to compile the compilier itself until it can compile itself.

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days 20 Hours ago by: Dave Froble

Why not? I can imagine it.

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days 21 Hours ago by: Richard Maher

Ok it looks like if you use Apple iCloud KeyChain the keys are "synched" with the cloud. I'd rather have to register new devices if I lost them all. And, as usual, looks like Apple won't recognize non-Apple devices :-(

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 17 Days 21 Hours ago by: Richard Maher

FFS what a bunch of arseholes :-( Bluetooth is on the "client" the "device" part of "multi-device". Your VMS code needs to be able to contact the authenticator of the public key who will ask the client device for something like an atte

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 17 Days 23 Hours ago by: Arne_Vajhøj

Cute with dynamic in Fortran. But more oldfashioned: PROGRAM GETMSG_FIXSTR INCLUDE '(LIB$ROUTINES)' INTEGER*4 STATUS,MSGLEN CHARACTER*256 MSG STATUS = 2928 CALL LIB$SYS_GETMSG(STATUS

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days ago by: Arne_Vajhøj

You did. Early April. But I was curious for whether there were an update. I think it is fair to say that native compilers are important for the perception of how "ready" VMS x86-64 is. That is not necessarily a good or fair criteria,

Re: X8691AOE boots OK - X8692OE fails as follows (thread)

comp.os.vms

Posted: 18 Days 1 Hour ago by: Mark Daniel

Just received new reading glasses but that's not my excuse this time. Was just puddling around on the https://sp.vmssoftware.com/ page and think I've always been distracted by the pull-down menus and never explored the icons on the far

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS (thread)

comp.os.vms

Posted: 18 Days 1 Hour ago by: chris

I would expect a C compiler to be part of an OS these days, or just a package download, not so much C++. Even early unix machines had a minimum of pcc, which was enough to build an early gcc and associated tools. An OS is useless without

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 18 Days 1 Hour ago by: John Reagan

Didn't I just do that a few weeks ago? I think I did. We're working on native BLISS, native C, and native C++ right now. All three are in various stages of "done". We've been tracking down a memory corrupter in the native C compiler for

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days 2 Hours ago by: Dave Froble

Seems to me, if they knew that, some of them would already be available. Knowing what is needed to be done just needs man hours. Trying to figure out what must be done sort of waits for "eurika, I've figured it out", and that is sort

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days 4 Hours ago by: Arne_Vajhøj

What are current ETA's for the various native compilers? Arne

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 6 Hours ago by: Andy Burns

But there's an expectation that the primary/sole console "owns" the bluetooth devices ...

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 6 Hours ago by: Andy Burns

how does it know which user is controlling the radio, which security token belongs to which user, etc? but who runs a web browser on VMS now? I suspect there's only one person here that does

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 18 Days 7 Hours ago by: VAXman-

PROGRAM GETMSG_DYNSTR IMPLICIT NONE INCLUDE '($DSCDEF)' INCLUDE '($SSDEF)' INCLUDE '(LIB$ROUTINES)' INCLUDE '(STR$ROUTINES)' INTEGER*4 STATUS RECORD /DSCDEF1/ DYNSTR

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days 7 Hours ago by: Dave Froble

No problem John. I have faith in you. I'm also aware that you're faced with a rather large task. Take your time, do it right.

Re: Disk Geometry (was: Re: SIMH disk geometry help required please) (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: Stephen Hoffman

Skim what material was explicitly referenced. Particularly the two sections that describe how the OpenVMS SCSI-2 implementation (and other SCSI-2 implementations) _added_ that addressing support. The original question is back in the

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: Stephen Hoffman

Maybe "Bluetooth on a server-focused operating system?" is a better statement of your concern here? Why? macOS, Linux, and various other multi-user systems all offer Bluetooth connectivity. The following reply mixes both two-factor a

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: HCorte

Thanks @Steven Schweda

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: John Reagan

Which compilers? Oh, never mind, you mean BASIC. :) BASIC will not be ready in the July timeframe (even if you include July 32nd). As I've mentioned before, BASIC presents an additional challenge on how it describes the MAP statement t

Re: Error Handling - Fortran (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: Steven Schweda

HELP SYSTEM_SERVICES $GETMSG HELP RTL_ROUTINES LIB$ LIB$SYS_GETMSG

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 18 Days 8 Hours ago by: John Reagan

Other than Macro, compilers are layered products. If you want to use the word "production" to mean "also has a minimum set of layered products", then go for it. For the record, we will not have all of the compilers ready as native compi

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 9 Hours ago by: John Reagan

Personally I prefer Steve Gibson's SQRL solution which is also passwordless. But I do realize that the momentum of FIDO and the backing of Apple, Google, and Microsoft will put SQRL into the dustbin along with Betamax tapes. https://www.

Error Handling - Fortran

comp.os.vms

Posted: 18 Days 9 Hours ago by: HCorte

INTEGER*4 FUNCTION HANDLER(SIGARGS, MECHARGS) IMPLICIT NONE C INCLUDE '($LIBDEF)' INCLUDE '($STSDEF)' INCLUDE '($SSDEF)' C INTEGER*4 SIGARGS(*) INTEGER*4 MECHARGS(*) C INTEGE

Handle a fortran Error/exception

comp.os.vms

Posted: 18 Days 9 Hours ago by: HCorte

INTEGER*4 FUNCTION Handler(SIGARGS, MECHARGS) OLMERRHANDLER = SS$_RESIGNAL C RETURN END

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days 9 Hours ago by: Dave Froble

Note the wording, perhaps their "get out of jail free" card? "first limited production release of OpenVMS on x86, V9.2, is scheduled for July 2022" Key word, "limited". My opinion, without native compilers, it would not be "production

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 11 Hours ago by: Simon Clubley

Well VMS does have (somewhat limited) USB support. :-) More that multiple people use a VMS server that is not physically close to them and uses a variety of means to connect to it, only some of which could be used with bluetooth based a

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 18 Days 11 Hours ago by: Simon Clubley

Yes, but July 1st, or July 32nd ? Also :-) Simon.

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86 (thread)

comp.os.vms

Posted: 18 Days 12 Hours ago by: Simon Clubley

General hypervisor support is a far better tradeoff for VSI to be pushing for at this point, rather than bare metal support on just a few hardware boxes, especially given the general trends in the industry. BTW, if it's a production rele

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 12 Hours ago by: Bill Gunshannon

What does multi-user have to do with it? bill

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 12 Hours ago by: David Jones

Since a dog only has 1 head, that make FIDO a third as good as Kerberos?

Re: C compiler snag (thread)

comp.os.vms

Posted: 18 Days 12 Hours ago by: David Jones

It's not the ".c", it's the general quirkiness how the CRTL (which the compiler uses) converts unix-style paths to VMS specifications. Trying defining the logical name DECC$POSIX_COMPLIANT_PATHS to the value 2, which makes it work on my s

Re: FIDO is a *MUST* (thread)

comp.os.vms

Posted: 18 Days 18 Hours ago by: Andy Burns

bluetooth support on a multi-user O/S ?

Re: C compiler snag (thread)

comp.os.vms

Posted: 18 Days 19 Hours ago by: Steven Schweda

Did you ever try that? Do you mean as in the demonstration above, where the following worked properly?: #include "a.d.g" Guess again? its $ type jh2.c #include "a.d.g" #include "sd/b.g" #include "sd/a.d.g" its $ cc /noobj

FIDO is a *MUST*

comp.os.vms

Posted: 18 Days 20 Hours ago by: Richard Maher

Please put FIDO2 next after Hypervisor support https://fidoalliance.org/apple-google-and-microsoft-commit-to-expanded-support-for-fido-standard-to-accelerate-availability-of-passwordless-sign-ins

Re: C compiler snag (thread)

comp.os.vms

Posted: 18 Days 21 Hours ago by: abrsvc

My first guess of the "problem" is perhaps the part of the specification ".c". Is this being interpreted as a file extension for a source file rather than parsed as part of the entire file spec? Try changing the .c to .x and try again.

Re: C compiler snag (thread)

comp.os.vms

Posted: 18 Days 21 Hours ago by: Craig A. Berry

If you want those include directories to work with relative paths in #include directives having relatvie paths and Unix syntax, you'd probably need to replace: /INCLUDE=([]) with /INCLUDE=("./") Do you have DECC$EFS_CHARSET defined

Re: C compiler snag (thread)

comp.os.vms

Posted: 18 Days 22 Hours ago by: Steven Schweda

Looks to me like a different problem. That's not the actual problem. Many "UNIX-style paths" work just fine. Simple paths with multiple dots also seem to work. _Your_ case fails: its $ type jh.c; #include "a.d.g" #include "

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 18 Days 23 Hours ago by: Richard Maher

Great Stuff!

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 19 Days ago by: Dave Froble

Yeah, I was about to post the info, but you beat me to it. :-) Too bad about the "bare metal" support. Whatever will Phillip do? :-)

Re: VSI Announces Initial Focus on Hypervisor Support for OpenVMS on (thread)

comp.os.vms

Posted: 19 Days ago by: Arne_Vajhøj

I guess that makes sense: - many want specifically to run in VM - even those that don't can run in VM with little extra work - VM is easy HW support wise - physical is complicated HW support wise So July is it. :-) Arne

Re: C compiler snag (thread)

comp.os.vms

Posted: 19 Days ago by: Jake Hamby

Resurrecting this thread: did anyone ever find a resolution to the problem of the C compiler not being able to find headers when they're referenced in quotes with UNIX-style paths? I had trouble with the build script from VSI's Python 3.1

VSI Announces Initial Focus on Hypervisor Support for OpenVMS on x86

comp.os.vms

Posted: 19 Days 2 Hours ago by: Jan-Erik_Söderholm

Maybe others have seen this, but I just got this announcement from VSI. Regards, Jan-Erik. After analyzing customer feedback, VMS Software Inc. has made the decision to move hypervisor support on OpenVMS V9.2 to the top of our priority

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 19 Days 3 Hours ago by: Jake Hamby

Thanks, that's *exactly* what I was hoping to hear! I'll give it a try. Cheers, Jake

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 19 Days 13 Hours ago by: Volker Halle

Steven, the following call is the lowest common call in ALL of your 4 SHOW CALL output files: SHARE$MOD_SSL_CODE2 0000000000DC9CA0 0000000000DC9CA0 But without the source code and the linker map, what does it help

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 19 Days 14 Hours ago by: Volker Halle

Steven, if looking at your ANALYZE/PROCESS output, you'd know, who to ask (look at the source code tree name). If you have a looping process, you could issue a couple of SDA> SHOW CALL/SUMMARY commands and compare the output. This might t

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 19 Days 19 Hours ago by: Steven Schweda

I might get around to it eventually. I looked at SHOW CALLS in a set of four process dump files. As I read these, starting from the bottom of the SHOW CALLS list, it got into a pile of common SHARE$MOD_SSL_CODE2 stuff, and then d

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 19 Days 21 Hours ago by: Roger Ivie

yeah, well, the manual also says that sem_timedwait takes an absolute timeout. it doesn't.

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 20 Days 3 Hours ago by: Craig A. Berry

You're right. I hadn't noticed the docs said this, i.e., bottom of page 118 here: https://vmssoftware.com/docs/VSI_CRTL_REF.pdf However, in the reference section for exit(), page 307 of that manual, it also says: ----- Beginning wi

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 20 Days 5 Hours ago by: Jake Hamby

I'll do that, thanks. Yes, I'm aware of that, which is why the current behavior does make sense, but the problem is that the C RTL reference manual tells me specifically to call exit() or _exit() from the child in case of failure. Other

Re: Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha (thread)

comp.os.vms

Posted: 20 Days 11 Hours ago by: Craig A. Berry

You may want to look into decc$set_child_standard_streams and/or decc$set_child_default_dir. As far as I know, until the exec succeeds, you don't actually have a child process. This is the documented behavior of vfork() on VMS, which i

Bizarre vfork() / exec() behavior in VMS V8.4-2L1 Alpha

comp.os.vms

Posted: 20 Days 16 Hours ago by: Jake Hamby

I recently got interested in the Rexx language as part of learning about IBM mainframes, and discovered that it's a good scripting language for other platforms as well. So why not port Regina (free Rexx interpreter) to VMS? After all, I've

Re: Restoring image and incremental BACKUPs: Why more than one incremental? (thread)

comp.os.vms

Posted: 21 Days 1 Hour ago by: Steven Schweda

Huh? What, exactly, is the same as what, exactly? After a BACKUP /IMAGE /RECORD, the first (partial) BACKUP /SINCE = BACKUP [/NORECORD] could be thought of either way. After that, they're all "differential", not "incremental". U

Re: Restoring image and incremental BACKUPs: Why more than one (thread)

comp.os.vms

Posted: 21 Days 5 Hours ago by: wdz

Many years ago when backup emerged the explanation was: If you restore incremental savesets forward then each different version of a file has to be written to disk until you get the most recvent version If you restore incremental saves

Re: Restoring image and incremental BACKUPs: Why more than one incremental? (thread)

comp.os.vms

Posted: 21 Days 10 Hours ago by: abrsvc

Since you indicated that the record pass was done only on the image backup, the incremental and differential are the same. If the record pass is done at each incremental pass, than the restore effort would be different.

Re: Restoring image and incremental BACKUPs: Why more than one incremental? (thread)

comp.os.vms

Posted: 21 Days 11 Hours ago by: Steven Schweda

Thanks. It's possible that when I devised this scheme (20-30 years ago?), it all made sense. I thought that it still did, until I read the current documentation. I've seen descriptions like "Incremental = since last backup", and "

Re: Restoring image and incremental BACKUPs: Why more than one incremental? (thread)

comp.os.vms

Posted: 21 Days 12 Hours ago by: abrsvc

As you surmise, restoring the most recent incremental will result in the disk having the state at the time of that incremental backup since the record pass was done only at the /IMAGE date. Other incremental savesets will contain files t

Re: Restoring image and incremental BACKUPs: Why more than one incremental? (thread)

comp.os.vms

Posted: 21 Days 20 Hours ago by: Steven Schweda

%BACKUP-I-SYMNOTFLW, <file_spec> is a SYMLINK and BACKUP will not follow the link

Restoring image and incremental BACKUPs: Why more than one incremental?

comp.os.vms

Posted: 21 Days 20 Hours ago by: Steven Schweda

It's been too long since I had to recover from a disk failure. (This one isn't especially critical, but I wouldn't mind losing as few data as possible.) (With decade-old disks, you might think it'd happen more.) I have a recent sa

Re: Disk Geometry (was: Re: SIMH disk geometry help required please) (thread)

comp.os.vms

Posted: 22 Days 7 Hours ago by: Johnny Billquist

Uh? Say what? Are you claiming that SCSI-2 and older would not support disks larger than 8.58GB??? I can't even see how any SCSI command could have an 8.58GB limit. 8.58GB limit would imply a 24-bit block address upper bound. However, i

Re: Disk Geometry (was: Re: SIMH disk geometry help required please) (thread)

comp.os.vms

Posted: 22 Days 8 Hours ago by: Stephen Hoffman

The only remaining part of OpenVMS that cares about disk geometry was part of the alternate home-block lookup support within mount-related processing, and newer volume initialization no longer use geometry to determine the alternate h

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 22 Days 23 Hours ago by: Simon Clubley

For anyone interested, the reason why the Alpha simulator is not usable is because there are none of the devices implemented that would be required in order to turn it into a full system emulator. Simon.

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 22 Days 23 Hours ago by: Simon Clubley

The Alpha simulator in simh is not usable so that's probably why. :-) Simon.

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 1 Hour ago by: Milton Baar

Thanks, will try recompiling the VAX with the additional compiler directives and see what happens :)

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 1 Hour ago by: David Wade

The docs for SIMH 3.10 http://simh.trailing-edge.com/pdf/simh_doc.pdf says:- "The PDP-11 and VAX simulators optionally support disks and serial devices files greater than 2GB. To include large device support, both USE_INT64 and USE_A

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 2 Hours ago by: Gremlin

"But first of all, you also need to check that simh, and the OS you are Can't find anything in the user documentation... :(

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 2 Hours ago by: Gremlin

" _How_ exactly was it copied ? " On the Charon emulator, OpenVMS was gracefully shutdown, Charon was closed, vdisks were copied to USB. Charon restarted, OpenVMS restarted, emulated system still happily running... All copied disks othe

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 5 Hours ago by: Johnny Billquist

Disk geometry is just arbitrary information with no impact here. Your problem is something else. A SCSI disk (or MSCP) is just a stream of blocks numbered from 0 to n-1. What you absolutely need to do is make sure the number of blocks

Re: is there another key exchange for ssh? (thread)

comp.os.vms

Posted: 23 Days 6 Hours ago by: Stephen Hoffman

TCP/IP Services V5.7 ECO5o had newer diffie-hellman-group14-sha1. That key exchange KEX was minimally adequate for connections from and to most other platforms. If you didn't want to downgrade the other end of the connection. ECO5o w

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 23 Days 7 Hours ago by: chris

Avery useful feature. Tyical scenario might be where an older machine is upgraded to a later machine. Older machine might have a mirrored os / root drive, then a second mirrored pair or raid 5 set for data, both with hot swap spares or no

Re: is there another key exchange for ssh? (thread)

comp.os.vms

Posted: 23 Days 9 Hours ago by: Craig A. Berry

Yes, diffie-hellman-group14-sha1 has been available, but that's probably not good enough for your client either. Right. About a month ago there was an ECO for TCP/IP Services 5.7 with ECO5X in the name that includes diffie-hellman-gro

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 10 Hours ago by: Simon Clubley

_How_ exactly was it copied ? On the disks that work ok, does the disk geometry match or is it different ? If it's different for the working disks and they still work, then that might indicate the geometry isn't the problem. Simon.

Re: is there another key exchange for ssh? (thread)

comp.os.vms

Posted: 23 Days 10 Hours ago by: Simon Clubley

IIRC, VSI released an updated set of algorithms as a patch for the very latest version. What version are you runninig ? Simon.

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 10 Hours ago by: Dave Froble

It's been a while, and my memory isn't always so good, but I believe that VAX/VMS V7.2 had some changes to directories. Never heard of a problem using disks from prior versions.

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 11 Hours ago by: gah4

I remember in the early days of using SCSI disks with Unix systems, we had to make up disk geometry. The only important thing was getting the total number of sectors right. The product of the numbers above for Simh doesn't give the ri

is there another key exchange for ssh?

comp.os.vms

Posted: 23 Days 13 Hours ago by: VAXman-

Is there another key exchange algorithm in TCPIP services ssh other than diffie-hellman-group1-sha1?

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 15 Hours ago by: Volker Halle

Gremlin, OpenVMS does not care much about disk geometry, except in some cases relating to file placement. Did you run ANALYZE/DISK on the original disk ? Do you see the same error messages ? If you believe, there is a problem caused by g

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 16 Hours ago by: Gremlin

Here's some output... Analyze/Disk_Structure for _$2$DUB2: started on 1-MAY-2022 17:24:45.04 %ANALDISK-W-CHKSCB, invalid storage control block, RVN 1 %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS -SYSTEM-W-BADIRECTORY, bad directory f

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 17 Hours ago by: Gremlin

I can't change anything on the CHARON-VAX installation as it is a production site. Although the ANALYZE/DISK errors may be interesting, the *,ain* issue is that SimH has the disk geometry all wrong and therefore ANALYZE/DISK will produce

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 17 Hours ago by: Volker Halle

Gremlin, if you want and/or can, you could change the disk geometry on the CHARON-VAX to reflect what SimH is setting up as the geometry and see, if the same errors then also show up on CHARON-VAX. The geometry information is not stored in

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 18 Hours ago by: Gremlin

VAX/VMS 7.3 on SimH trying to use an disk image from VAX/VMS 7.1 On SimH: mou/over=id $2$dub2 %MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked %MOUNT-F-BADSECSYS, failed to create or access SECURITY.SYS -SYSTE

Re: SIMH disk geometry help required please (thread)

comp.os.vms

Posted: 23 Days 18 Hours ago by: Volker Halle

Gremlin, could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ? Volker.

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 23 Days 20 Hours ago by: John Nebel

Volker, Running out of global sections will definitely make CSWS go berserk, easy enough to check that possibility. John On 4/30/22 7:27 AM, Volker Halle via Info-vax wrote:

SIMH disk geometry help required please

comp.os.vms

Posted: 23 Days 21 Hours ago by: Gremlin

I have a Charon-VAX disk image of an RZ59 which I am trying to use on SimH v3.9. I can configure the disk in the SimH ini file using "set rq0 rauser=9114" which should (?) indicate that it is a 8.9GB storage device. When I start OpenVMS

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 23 Days 23 Hours ago by: chris

FreeBSD disk block size is always 512 bytes. The host adapter may use larger block sizes as part of the error handling scheme, but FreeBSD would never see that You could try downgrading to NFS V3, rather than 4, but unless you can verify

SUCCESS Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 24 Days ago by: Matthew R. Wilson

SUCCESS! It turns out there was another confounding factor in my experiments: dodgy hardware. Not sure if it's a dirty optic, failing SFP port, or what. But I switched to doing some heavy I/O testing by installing Linux on the Itanium sy

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 24 Days 6 Hours ago by: dthi...@gmail.com

You might also try bumping FreeBSD down to SPC3 to see what happens if you're not having any other progress. I recall having to go through some protocol debugging with HPE when they added SPC4 support for the BL860 SAS SSDs which we wanted

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 24 Days 10 Hours ago by: Volker Halle

Steven , all those PCs reported are system space PCs. Using SDA> MAP <address> you might get ideas, which routines are involved. Access violations on the stack should not be 'normal' and can be indications of software problems futher down

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 24 Days 10 Hours ago by: Volker Halle

Matthew, consider to use the DKLOG SDA extension to find out the details about the IOs done during the INIT command: $ ANALYZE/SYSTEM

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days ago by: Stephen Hoffman

Various Compaq, HP, and HPE Smart Array controllers are supported on OpenVMS, and have some nice features. Some is commonly used as core I/O on some of the Integrity Itanium servers. The Smart Array x86-64 BIOS configuration stuff is

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 1 Hour ago by: Stephen Hoffman

The sorts of ancient and slow HDDs and parallel SCSI that you're familiar and accustomed to? No. That written, much of the available x86-64 storage uses SCSI commands. SAS, ATAPI, iSCSI, iSER, SATA with SCSI translation, most USB st

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 1 Hour ago by: chris

May be irrelevant, but HP Smartarray controllers, have built in firmware to define various raid levels and are trivial to setup from bios. Not only that, but a failed raid member can typically be physically replaced with no host intervent

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 25 Days 1 Hour ago by: Steven Schweda

Extracting the data is easier after "SET TERM /DEVI = LA120". A few minutes' sample of "Current PC" lines should be here (unsorted, and after "SORT /KEY = (POSI: 16, SIZE: 17)": http://antinode.info/vsi/csws_loop_3.log_cpc

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 4 Hours ago by: gah4

(snip) As well as I know, all SATA disks will also accept SCSI commands, and many systems run them that way. My choice would be NFS, though.

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 25 Days 4 Hours ago by: Matthew R. Wilson

After further experimentation, I think the READ LONG exceptions are red herrings. I think VMS is issuing the READ LONG commands to determine if the target supports the command, and if so, what the correct byte transfer length value is. I

Re: VMS to VMS data copy options/performance when losing a DECnet link (thread)

comp.os.vms

Posted: 25 Days 5 Hours ago by: Rich Jordan

Mark Unfortunately the two servers are not colocated; one is remote connected by some config of their 'metropolitan area network' but we have no control or access over that, We have tried tweaking the sysconfig settings on both

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 8 Hours ago by: Stephen Hoffman

READ LONG (3eh) is deprecated in current standards, while WRITE LONG (3fh) is mostly-deprecated. The write-uncorrectable feature is still part of SBC-5. Otherwise, not so much. Host-based RAID-1 HBVS also works with devices that don't

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 8 Hours ago by: Mark Berryman

Read/Write Long was marked obsolete more than a decade ago. Thus, I would think that if it had a negative impact on any of VSI's customers, they would have let VSI know. Multi-site clusters are actually one of the strengths of SAN.

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 8 Hours ago by: abrsvc

I don't think you can state that HBVS breaks as the restriction exists today and has for quite some time. I would guess that the restriction didn't raise a lot of reports with VSI which is one reason for it not being addressed (not addre

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 8 Hours ago by: Phillip Helbig (undr

In article <68f2137f-d0e6-4921-98ee-854022f7d751n@googlegroups.com>, abrsvc <dansabrservices@yahoo.com> writes: Merely the fact that most don't expect such an essential feature to break should be reason to address it. SAN? Yes, can pr

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 8 Hours ago by: Phillip Helbig (undr

In article <t4gkmn$5fo$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: Interesting. What is affected? Alpha? X86? Both? Only VSI VMS? Will anyone use SCSI disks on x86?

Re: Volume shadowing and current SCSI standards ? (thread)

comp.os.vms

Posted: 25 Days 11 Hours ago by: abrsvc

The current HBS product requires the use of the READ/WRITE LONG commands so you are correct HBS won't work with devices that don't support it. Many customers now use SAN devices and the "shadowing" takes place there rather than being hos

Volume shadowing and current SCSI standards ?

comp.os.vms

Posted: 25 Days 11 Hours ago by: Simon Clubley

[snip] Interesting, because that has serious implications for using VMS with modern hardware, especially on x86-64, if true. If this statement is correct, does this mean that VMS volume shadowing will no longer work with devices which

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 2 Hours ago by: Matthew R. Wilson

Interesting. The wording in the Volume Shadowing Guide seem to imply that VMS itself would work with devices that don't support READ/WRITE LONG, but you shouldn't use them with Volume Shadowing. It seems like for FC devices, the support

Re: vax vms licenses

comp.os.vms

Posted: 26 Days 5 Hours ago by: Phillip Helbig (undr

In article <t4ek6e$a0e$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes: If the lack of perpetual licenses is a potential show-stopper for me as a hobbyist, it must be even more so for many co

Re: vax vms licenses

comp.os.vms

Posted: 26 Days 6 Hours ago by: Phillip Helbig (undr

In article <t4ejjt$orl$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: Right. The question is what VSI's justification is. But did that come from VSI? Indeed. Does anyone?

Re: vax vms licenses

comp.os.vms

Posted: 26 Days 6 Hours ago by: Simon Clubley

I suggested that in detail here in COV. IIRC, the French people suggested it to VSI and VSI rejected the idea outright. There were suggestions here that such an idea might affect the future resale value of VSI if they go bust and there

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 26 Days 6 Hours ago by: Phillip Helbig (undr

In article <jcvk51Fp8okU1@mid.individual.net>, Hans Bachner <hans@bachner.priv.at> writes: No, but I've been there a few times, and indeed once to pick up some hardware. :-)

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 26 Days 10 Hours ago by: Hans Bachner

Probably to pick up some hardware... Hans :-)

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 13 Hours ago by: John Wallace

READL (aka "read long") and the equivalent write command are important parts of VMS volume shadowing - so important they're even mentioned in the Software Product Description. Have a read (if you haven't already done so), see if it helps

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 26 Days 14 Hours ago by: Andy Burns

Which my German car does using an LTE modem.

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 15 Hours ago by: Matthew R. Wilson

Progress!!! After looking at the data from Volker's system, the most obvious difference in the initial standard INQUIRY response is that his DGA device was reporting SCSI version 2. FreeBSD's SCSI target implementation reports SPC5. SPC5 a

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 26 Days 15 Hours ago by: Phillip Helbig (undr

In article <t4ckbo$6un$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: Well, my phone still works, while those with newer (but still old) protocols don't. Why were they switched off and the older o

Re: vax vms licenses

comp.os.vms

Posted: 26 Days 15 Hours ago by: Phillip Helbig (undr

In article <t4cl6b$6un$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: Indeed. The fact that many here can't get a VAX license shows that the fear is real. We have seen VMS owned, and neglected,

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 17 Hours ago by: Matthew R. Wilson

Thank you Volker! Having all of the good responses from a working target could go a long way to working out what's required to support VMS. Lots to look over, but I found that some of the sg3-utils tools on Linux can help decode messages

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 18 Hours ago by: Volker Halle

Matthew, the value 132 is the system service status code: VSIAXP $ exit 132 %SYSTEM-F-DEVOFFLINE, device is not in configuration or not available Here is the SCSI_INFO data from an emulated DGA device on a CHARON-AXP emulator: VSIAXP $

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 19 Hours ago by: Matthew R. Wilson

Ah... that could help! Perhaps a useful clue: $ scsi_info $1$DGA2: $! $! SCSI_INFO X-5 $! $! Copyright (c) 2019 by VMS Software, Bolton Mass. $! All Rights Reserved. Unpublished rights reserved under the copyright

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 20 Hours ago by: Robert A. Brooks

$ scsi_info :== sys$etc:scsi_info $ scsi_info $1$dga1:

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 26 Days 21 Hours ago by: Matthew R. Wilson

Hi David, Thanks for your thoughts. Doesn't look like a visibility problem. OpenVMS sees the target and LUNs just fine; it creates the DGAxx devices that correspond to the LUNs with the correct UDID, and SYS$ETC:FIBRE_SCAN reports everyt

Re: vax vms licenses

comp.os.vms

Posted: 26 Days 21 Hours ago by: Craig A. Berry

It mostly just hasn't come up yet. Where I work we have done 3-year contracts with VSI, first in 2017 and then renewed once in 2020, so 2023 will be the first time we will be up for renewal when *possibly* there will be an opportunity t

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 27 Days ago by: dthi...@gmail.com

You may also have a zoning visibility problem or a host behavior definition problem. Make sure that both the FC switch and the FreeBSD UDID source allows read/write access from the WWIDs of the Integrity systems, and that they are all in t

Re: vax vms licenses

comp.os.vms

Posted: 27 Days ago by: Simon Clubley

People don't have to worry about either Microsoft or Oracle going bust in a few years. They do have to worry about if they go with this small non-mainstream company called VSI, will they lose their job in a couple of years if VSI goes bu

Re: vax vms licenses

comp.os.vms

Posted: 27 Days ago by: chris

Perhaps VSI have presented this issue in the wrong way. Had they stressed from the start that the licensing was subscription based, there may not have been such a negative response. As you say, that seems to be the direction in industry a

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days ago by: Simon Clubley

Moving to Norway, Phillip ? :-) Any errors logged ? If so, anything useful in the error log ? Anything useful in operator.log ? Simon.

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days ago by: Simon Clubley

How long will the 2G and 3G networks continue to be supported in Germany ? Simon.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days ago by: Simon Clubley

If you are not running real VAX hardware, but just an emulator, then switch to an Alpha emulator, install the VSI community version of Alpha VMS, and then call it job done. There are some Linux based Alpha emulators but their emulation a

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 1 Hour ago by: David Goodwin

Yeah, I guess that really is the bigger issue. There is never any guarantee I'll have access to OpenVMS beyond the end of my current community license. So I'm never going to invest more time and effort into OpenVMS than I'd be willing to

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 1 Hour ago by: Kerry Main

license Keep in mind that there are major SW licensing changes happening with other vendors as well. Case in point - Microsoft changing their SQL licensing to a core based model similar to how Oracle does its licensing. With HW vendors

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 2 Hours ago by: Jan-Erik_Söderholm

Yes, we have. And *you* have no idea, what so ever, why. You said that we would not have any use of the things that are IA64-only, and you have absolutely no knowledge about that. The reason is of course that we have some things that are

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 2 Hours ago by: David Goodwin

No solution that doesn't involve paying thousands of dollars or running it without a license

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 2 Hours ago by: David Goodwin

Over time existing customers will leave. Either they go out of business, change the sort of work they're doing, or whatever it it is their OpenVMS systems are doing is simply no longer required. Some will probably even migrate to Linux be

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Phillip Helbig (undr

In article <6269a5c3$0$696$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_VajhÞj?= <arne@vajhoej.dk> writes: Indeed; about a quarter of a century. But runs fine and if it dies I have replacements which I can swap in. I'm still using a N

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Phillip Helbig (undr

In article <memo.20220427170059.3264G@jgd.cix.co.uk>, jgd@cix.co.uk (John Dallman) writes: Where is Elon Musk when you need him? :-) OK, it was about 25 years ago, but Compaq paid 9 billion for DEC and Musk paid 44 billion for Twitter

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Phillip Helbig (undr

In article <t4bna1$1lkl$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes: Went to my Norwegian course, came back, and startup was still hung. Rebooted the machine. There was enough connecti

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Arne_Vajhøj

It is a long time since that PWS rolled off the assembly line ... :-) Arne

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Phillip Helbig (undr

In article <t4bone$f31$1@gioia.aioe.org>, chris <chris-nospam@tridac.net> writes: I had indeed forgotten to connect the keyboard the first time I saw it, but after I had connected it, sometimes it was there and sometimes not.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 3 Hours ago by: Attila Ruzsinszky

I asked about OpenVMS for VAX license. VSI doesn't work with VAX. I'd like to use SIMH VAX program with OpenVMS. Learning or testing. Without real VAX hardware ... So there isn't any solution? It sounds bad! :-(

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 5 Hours ago by: Dave Froble

Correct, so where do all these claims such as that above come from? One could speculate that HPe paid VSI to take VMS off their hands. Not that I think such happened, but speculation is so wide open, and so few facts. Also note that

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 6 Hours ago by: Arne_Vajhøj

It seems likely that VSI has paid something, but whether it was a one time lump sum or an annual amount or a percentage of license revenue or the symbolic 1 dollar or something else has as far as I know not been public disclosed. Note th

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 6 Hours ago by: Dave Froble

What knowledge or evidence do you have that HPe is still getting any money from VSI? I've never heard of any such payments, but then again, perhaps such would not be common knowledge.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 8 Hours ago by: John Dallman

From what I know about Oracle, that was never in prospect. Their reason for buying Sun was to be able to optimise the SPARC hardware and Solaris to improve Oracle DB performance and get a more compelling offering than Oracle DB on other

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 8 Hours ago by: chris

My guess would be that the video monitor may not respond to serial port input, that is, either serial port or kbd / monitor modes, not both. It may default to serial port if no keyboard detected... Chris

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 8 Hours ago by: Phillip Helbig (undr

OK. Not sure why the startup is so slow, but things seem to be working fine again. (Perhaps the fact that I'm not using the fastest hardware I have is a factor!) Interestingly, according to OPERATOR.LOG there was a full shadow copy (no

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 9 Hours ago by: Phillip Helbig (undr

In article <t4bkmt$dhi$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes: OK, after a few power cycles, sometimes the error message appears, sometimes not. When it didn't, I could get into th

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 9 Hours ago by: Phillip Helbig (undr

In article <t4bkia$b4e$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes: Monitor is a DELL 1905FP which I have used with a wide variety of VMS systems, but possibly never with a PWS. I could

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 9 Hours ago by: Phillip Helbig (undr

In article <t4bk07$3k5$1@gioia.aioe.org>, helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes: Seems strange that they would actually support the console on a serial terminal but provide no method of actually sele

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 9 Hours ago by: Dave Froble

You have mentioned multiple times that your customer has 3 DS20E systems. Of course, you may also have access to an itanic ...

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 9 Hours ago by: Phillip Helbig (undr

In article <62694adb$0$703$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_VajhÞj?= <arne@vajhoej.dk> writes: Hmmm. Pulled the video cable from an AS1200/DS5000, connected it to the PWS, cycled the power, and got a message saying "analog i

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 10 Hours ago by: Arne_Vajhøj

I had a 433au but I do not remember ever doing this. For a different Alpha model I specifically recalled having to get a VGA monitor attached to do some stuff. And it sort of makes sense. AlphaBIOS = Windows NT, SRM = VMS or Tru64. Windo

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 10 Hours ago by: Phillip Helbig (undr

In article <jcsrvdF97deU1@mid.individual.net>, "Michael Kraemer @ home" <M.Kraemer@gsi.de> writes: That's correct, and works fine from a graphics console. IIRC there was some trick to get the menu working in the serial console. But ma

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 10 Hours ago by: Phillip Helbig (undr

In article <11ca43ed-6375-426a-b9fb-c1ea77384779n@googlegroups.com>, Steven Schweda <sms.antinode@gmail.com> writes: 433au. My recollection is that all "au" models are the same on this point. Right. While powering up, at first noth

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 11 Hours ago by: Michael Kraemer @ ho

my notes say: 1. Replace battery 2. In the AlphaBios setup, press F2 to choose CMOS setup 3. Choose F6 for "advanced setup", this allows to select SRM console 4. Press F10 to save the changes and PowerOff/On

Re: personal workstation: configure to boot VMS (thread)

comp.os.vms

Posted: 27 Days 11 Hours ago by: Steven Schweda

Which "PWS" model? My dim/unreliable recollection is that (with the dead Li cell) it defaults to the AlphaBIOS console, and you'd need a non-serial console connection to get it back to the SRM. I believe that I found (stumbled into

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 12 Hours ago by: Phillip Helbig (undr

In article <t4aeqg$vk1$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes: There is an obvious selection effect here: those who are fine with the license policy are fine being VSI customers. Those who aren't, aren't.

personal workstation: configure to boot VMS

comp.os.vms

Posted: 27 Days 12 Hours ago by: Phillip Helbig (undr

Due to some planned but notified-us-at-short-notice maintenance on the electricity supply today, I noticed that a battery in a personal workstation had gone bad and thus doesn't know what to boot after the power came back on. Had I had

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 27 Days 12 Hours ago by: Volker Halle

Steven, when closely looking at that stack output, I see 3 Access Violations on the stack: 00000000.7ACC8EC8 0000000C.00000005 <<< the 32-bit signal array 00000000.7ACC8ED0 00D2A2F0.0

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 16 Hours ago by: Jan-Erik_Söderholm

Why do you think that? And why do you think that our needs are the same as for everyone else?

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 19 Hours ago by: Dave Froble

Interesting. My daughter has done rather well getting both DirecTV and Dish to offer more, reduce rates, and such when she finds them making those special offers. Part of that is the willingness to mention the competitor and switch if

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 20 Hours ago by: Dave Froble

Or by telling the vendor they had better treat me as first class, or better, cause the highway is a calling. I do find it interesting that the worst doomsayers are those without any relationship with VSI. Any current customers with V

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 20 Hours ago by: Dave Froble

I don't see where this "anti-open source" comes from. Doesn't make any sense. Even if VMS was open source, VSI would still have their copy of it, and they would use and support that copy. If someone else wanted to do otherwise, fine,

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 21 Hours ago by: Bill Gunshannon

And now your back to the original point. People apparently have told VSI ans VSI apparently said "We will consider it for customers we consider special. For the rest, no." At that point if a customer decides to move off of VMS there is

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 22 Hours ago by: Arne_Vajhøj

Insisting on using open source is mostly for people in their 40's and 50's. Young people don't care. Fashion has changed. And besides much open source are now dominated by big software companies. Young people does typical not look lon

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 22 Hours ago by: Arne_Vajhøj

Based on available info they are profitable already. The natural order of events for VSI must be: 1) get VMS x86-64 completed 2) get existing customers migrated to VMS x86-64 3) modernize VMS 4) get new customers Not so sure. Today u

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 22 Hours ago by: Arne_Vajhøj

There is no guarantee that closed source will go EOL. It seems likely that at some point in time customers will want something newer and the product be dropped due to lack of demand. But in theory a closed source product could continue in

Re: vax vms licenses (thread)

comp.os.vms

Posted: 27 Days 22 Hours ago by: Arne_Vajhøj

OpenVMS users are not against closed source (for obvious reasons). But very few OpenVMS users are against open source. They already use lots of open source on VMS and on other platforms. Being anti open source is so 1990'ish. Arne

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Arne_Vajhøj

They would tell VSI before the decision is made to see if VSI will change their mind. Arne

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Bill Gunshannon

Why tell VSI? Once the decision has been made and money, time and effort invested in the move what would they expect to gain? bill

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Arne_Vajhøj

Business is business. If you go to McDonalds regularly then McDonalds give you points that you occasionally can use to get a free burger. Cloud providers does not customize their offerings unless someone like US DoD comes and talk about

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Arne_Vajhøj

They will tell VSI. But they will not tell the world. Companies very rarely explains stuff like that to the public. Arne

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Bill Gunshannon

So you have First Class customers and you have Second Class customers. If my vendor considered me a Second Class customer I would start looking for a new vendor. bill

Re: vax vms licenses

comp.os.vms

Posted: 27 Days 23 Hours ago by: Bill Gunshannon

I assumed we were talking about businessmen like the various French who appear to have been unable to get any acceptable information out of VSI. I was merely pointing out that it was unlikely they would then run around shouting "I'm leav

Re: vax vms licenses

comp.os.vms

Posted: 28 Days ago by: Arne_Vajhøj

If they want to stay on VMS then they would of course tell VSI what they want to see for them to be able to stay on VMS. It would be crazy to keep what they want a secret. VSI are not mind readers. Arne

Re: vax vms licenses

comp.os.vms

Posted: 28 Days ago by: Arne_Vajhøj

Probably only a handful of people at VSI knows that number. My best guess is that the number is very very small. Why? Because if it was not then VSI would have changed license policy! Paying customers standing in the door and saying th

Re: vax vms licenses

comp.os.vms

Posted: 28 Days ago by: Arne_Vajhøj

???? Everybody knows that is how business works. ???? If DEC has known that and provided the PC's, cheap fast work stations etc. that customers wanted then DEC would still exist. Arne

Re: vax vms licenses

comp.os.vms

Posted: 28 Days ago by: Arne_Vajhøj

Business is business. Based on what VSI has actually said then it seems highly likely. Quote from Terry Holmes: <quote> Having said the above, we do recognize that there are specific situations that are so important to human health an

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days ago by: Arne_Vajhøj

10 year old Itanium systems are faster than 20 year old Alpha systems. VMS x86-64 cross compilers are only available on Itanium. Java 8 is only available on Itanium - Alpha is left at Java 5. Lots of VSI provided open source ports are

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days ago by: Dave Froble

Ok, let's take a look at these claims ... What guarantees that one day it will no longer be possible to buy new licenses? What guarantees that one day security updates will no longer be available? What guarantees that one day security

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days ago by: Dave Froble

You don't seem to be missing them ... :-)

Re: vax vms licenses

comp.os.vms

Posted: 28 Days ago by: Dave Froble

I don't know any businessmen that are so passive. Most will get in a vendor's face and let them know what they want.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 1 Hour ago by: Crabs

I suspect that HP really doesn't care about enforcing it's licensing policy very much. I just did a quick search of eBay and found 10 or so Digital and HP license PAKS being offered up for resale. Crabs

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 2 Hours ago by: Jan-Erik_Söderholm

You can lookup he SPD's or similar. There are a lot of tools that are available on IA64 but not on Alpha.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 2 Hours ago by: David Goodwin

I don't see any sensible explanation for why having access to the source code is a bad thing or why it couldn't work for OpenVMS. If you're worried about some hidden security vulnerability then those exist whether the source is public o

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 2 Hours ago by: David Goodwin

Yeah, Illumos isn't popular or widely used. But its also not dead - something Solaris and OpenVMS will both be in a decade or two. Possibly Illumos would be more widely used if Oracle had chosen OpenSolaris as the path forward rather than

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 2 Hours ago by: John Dallman

I was. John

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 3 Hours ago by: Bill Gunshannon

The bad side of all this is I expect no one is going to publicly state they are leaving because of this. I expect that options other than VMS will be looked at and projects to move away from VMS will be started. The move will only become

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 4 Hours ago by: Dave Froble

If you're referring to the cross compilers for x86, that's rather short term, and native compilers would replace them. In John we trust ... If something else, be specific.

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 4 Hours ago by: Phillip Helbig (undr

In article <t47lt0$1pi$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes: It depends on how many there are and whether they would really walk if VSI stood firm.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 4 Hours ago by: Phillip Helbig (undr

In article <3a643f5c-5df8-4743-b466-a5ae1599aa38n@googlegroups.com>, David Goodwin <dgsoftnz@gmail.com> writes: If VMS were open source, it wouldn't work. Many point out the differences between VMS and other operating systems. One of

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 4 Hours ago by: John Dallman

For many purposes, sure, although building on an emulator is going to be slow. However, all the cross-tools that are currently only runnning on Idsel (I prefer that to Itanic) would have to be got going there. The stuff that uses LLVM wo

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 5 Hours ago by: Dave Froble

Yes, I have. Now address my question. Can you name one VMS customer that intended to stay on VMS but then walked away because of the licensing? Not someone complaining. Someone who actually walked away. There is ALWAYS a minimum of

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 5 Hours ago by: Dave Froble

I didn't say that a particular vendor would survive. I did seem to imply that if customers were not satisfied, a vendor could perish.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 5 Hours ago by: Dave Froble

I don't see anything like that? What can itanic do that Alpha cannot? It's a shared code base.

VSI TCP/IP Services for OpenVMS Tuning and Troubleshooting (thread)

comp.os.vms

Posted: 28 Days 6 Hours ago by: Mark Daniel

8< snip 8< VSI have responded, adding (quoted to prevent wrapping):

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 6 Hours ago by: Simon Clubley

David, have you read _anything_ that Gerard has posted ??? French users who _want_ to stay with VMS are being pushed away from VMS by the VSI licencing and the utter unwillingness of VSI to engage with the French users in any meaningful

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 6 Hours ago by: Simon Clubley

Read the original quote above. Itanium is currently used for things that Alpha cannot be used for. Of course, that ceases to be a problem once everything, including building VMS itself (and the compilers), is running natively on x86-64 V

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 7 Hours ago by: Bill Gunshannon

Where's the tongue-in-cheek emoji? You can't possibly be that naive. If that were true we would still be buying from DEC or at the very least HP would still be pushing VMS. bill

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 9 Hours ago by: Dave Froble

If emulators for building VMS is the issue, Alpha emulators already exist. Don't need no stinkin itanic.

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 9 Hours ago by: Dave Froble

How many customers have walked away? Can you name even one?

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 9 Hours ago by: Dave Froble

Standard customer rules: 1) The customer is always right. 2) When customer is wrong, refer to rule #1.

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 11 Hours ago by: Simon Clubley

The evidence coming out of France is that VSI are indeed allowing the customers to walk away rather than addressing the concerns of those customers when it comes to the time-limited production licences. Simon.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 11 Hours ago by: Simon Clubley

There are full system emulators for all architectures I am aware of apart from Itanium, which should tell you something. I once spent a weekend looking at the possibility of writing one, and came to the conclusion of basically "forget tha

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 28 Days 12 Hours ago by: abrsvc

Another potential option is to create a file with a number of "show proc/register" lines in it. Enter a "set process xxx" where xxx is the process that is looping followed by @filename (file created above). This will give you the regist

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 13 Hours ago by: Bill Gunshannon

Are you saying that VSI would give some people a better deal while the majority would be stuck with the original plan? You don't think that would drive them away? bill

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 13 Hours ago by: gah4

(snip) DEC nicely released the 36 bit OS for us to use, though with only (from them) out of production hardware. I am not so sure when emulators came out, but it would not have been hard to write one by then. I suspect VAX is nicer

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 28 Days 14 Hours ago by: Volker Halle

Steven, I'd start with SDA> SHOW CALL/SUMMARY. It should give you the list of routines called. If you compare this in multiple process dumps, you might spot some common routines towards the bottom of the call chain. Did you collect PC val

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 28 Days 15 Hours ago by: Ian Miller

the DKLOG or FC SDA extensions on VMS may provide more clues.

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 15 Hours ago by: John Dallman

Not all that widely used, though. My employers provided several products for SPARC Solaris for decades, and phased it out because Oracle were making less and less sense. Never had any customer interest in Illuminos, or even Solaris x64 w

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 28 Days 19 Hours ago by: Steven Schweda

Oops. http://antinode.info/vsi/APACHE$HTTPD.DMP http://antinode.info/vsi/APACHE$HTTPD_sda.out

Re: VSI I64VMS CSWS V2.4-48B subprocesses go bererk? (thread)

comp.os.vms

Posted: 28 Days 19 Hours ago by: Steven Schweda

It's been a while, but I did find some time to try a process dump of a few of the looping processes. I can't say that I learned much from 4000 lines of "Current Operating Stack (User)". I see a bunch of (meaningless-to-me): BUG$_LKBR

Re: vax vms licenses

comp.os.vms

Posted: 28 Days 21 Hours ago by: Dave Froble

What if a number of VMS customers, currently with support contracts, just declared "no, we won't accept that"? Do you really think VSI would let them just walk?

Re: vax vms licenses (thread)

comp.os.vms

Posted: 28 Days 22 Hours ago by: David Goodwin

As long as OpenVMS is as proprietary and closed source as it is I don't see younger people paying much attention to it. Its just not worth investing effort into something that could be taken away at any time. Most open-source projects ar

Re: Error using fibre channel target on FreeBSD from OpenVMS (thread)

comp.os.vms

Posted: 29 Days 1 Hour ago by: Matthew R. Wilson

There is a fibre switch (QLogic SANbox 5802V). It feels like it *should* be working because the OpenVMS system does see the LUNs and even assigns them device names (DGA1 and DGA2 corresponding to UDID 1 and UDID 2 that I assign on the ta

Re: vax vms licenses

comp.os.vms

Posted: 29 Days 6 Hours ago by: Simon Clubley

The alternative viewpoint is that their short-term aggressive licence policies could be scaring off VMS the customers who would have made up their long-term income. Simon.

702 recent articles found.

rocksolid light 0.7.2
clearneti2ptor