D3 error when logging into DM

[Rick Weiser]

Hi all,

We had to reboot a server running Windows D3 v9 because it was unresponsive and could not shut it down from windows services.  Now we get the following when we try to log into dm:

Frame Out of Range ; reg= 13  @  WRAPUP_SUB:000

O=Logoff / Q=Quit / <CR>=Go to debugger ?

Any ideas on how to fix this?

Thanks,

Rick

[Ross Ferris]

You have a corruption in the VME (from when you turned the power off) & you will need to restore "the (VME) blob" - either from a windows backup (EVERYONE using D3/Windows needs to have a copy of the VME blob that they can restore to solve this, and frame loss through the spooler) OR from a D3 backup (check the manual - I think your need a /restore rather than a /fileload - may have these reversed .... have I ever mentioned how much I dislike D3/Windows :-)

[Kevin Powick]

On Thursday, 19 November 2015 19:02:34 UTC-5, Ross Ferris wrote:

 

I think your need a /restore rather than a /fileload - may have these reversed .... have I ever mentioned how much I dislike D3/Windows :-)

 

If a VME restore is required, then yes, /restore is the command switch to use with D3VME.EXE

--

Kevin Powick  

[Rick Weiser]

Hi all,

I was able to shutdown d3 normally and then restart it.  I have not had the problem again.  I will let you know if it happens again.

Thanks,

Rick

[Ross Ferris]

If you don't already have one, grab a copy of the VME blob!!

[Kevin Powick]

On Friday, 20 November 2015 00:55:24 UTC-5, Ross Ferris wrote:

If you don't already have one, grab a copy of the VME blob!!

Agreed!  Get a save of it immediately.

SELECT MDS WITH A1 = "D"

SAVE (FDT 

--

Kevin Powick

[Peter McMurray]

The VME Blob is extremely valuable as a restore leaves the FSI accounts in situ. However you need to register it with the D3 device manager under tape devices for it to come up with the D3VME /RESTORE command. It is the simplest way of recovering lost frames when D3 has been knocked over by some event like a storm pulling the plug when everything is running. For those who may not know, Ross has a love of Linux whereas the greatest day in my life was getting rid of anything not Microsoft and Windows 10 runs fine just remember to set it for you to load updates so you can stop D3 before rebooting.

[Ross Ferris]

Unfortunately losing power isn't the only source of corruption in the D3 VME in D3/Windows and D3/NT before it (and totally ignoring /DOS).

Simply using the system & printing causes frames to disappear, a problem which hasn't been addressed in well over a decade. Obviously the problem can be solved, as you simply don't see this with D3/Linux or AIX.

Pity ... I've always liked the idea of /Windows, but the product has a number of fatal flaws.

[Peter McMurray]

Hi Ross

It seems that you haven't used D3 Windows for many years. We have never suffered the problems you mention. We switched to DOS and R83 around 1987 then OA and the only disasters we have had have all been on Unix variants. We paid for Pick/Unix experts and nobody ever solved issues 100%. The last Unix variant disappeared from our client list in favour of Windows server around 2000 and all the issues went with it. 

[Ross Ferris]

ummm ... wrong! Have the latest version of D3/Windows installed & contemplating if I want to play with current Beta to see what, if any, problems have been solved or introduced. As I keep saying, D3/Windows can be "OK" if you just run it like R83 ... try using some of the more advanced facilities & bad things happen - random aborts, unexplained VME space leakage, and have you ever had a corruption in FSI:dm? Not pretty.

IIRC your "unix" experience was with platforms like "Edge" -->  unproven platform running OA, and even on PC platforms OA was a dud that (quite rightly) I don't think Pick Systems ever sold in the wild --> speed was 25% of AP/Native .... they did get there with D3 on PC platforms, but Edge went to oblivion as an unfortunate blip on the radar. Had you opted for Seqoia, they had the people to make it work, and history would have been significantly changed.

[David Knight]

Hi Ross,

Perhaps we are coming at this from different angles, but I'm with Peter on this. d3/win and previous incarnations are fine. Yes, one needs a vme backup for restore; and yes I typically restore on most sites once or twice every year or two; due to vme frame loss. BUT those are tracked back to disconnects by telnet users not logging off before closing the client or network disconnects. I largely solve that by encouraging good practice, setting auto-logoff timeouts; and finally by making sure d3 is started/stopped correctly. Indeed one site has not needed a restore in years & is my largest site.

Now maybe this is as you say: because I use it 'R83-like'; so perhaps it is with the features to which you use; and maybe that makes it "fatal" for you; but to make a blanket statement is a bit of a stretch!

What are the 'advanced things' you speak of? What are the bad things? Oh, and I think I've only ever had a badly corrupt vme once. If one has a vme backup; it's an easy-peasy fix, which I can walk the client through in about 10 minutes, or do remotely in about 5.

My personal IT experience is I've had many time more issues with Windows or PC's themselves than with anything d3-related.

[Peter McMurray]

Ross Said

"IIRC your "unix" experience was with platforms like "Edge" -->  unproven platform running OA, and even on PC platforms OA was a dud that (quite rightly) I don't think Pick Systems ever sold in the wild --> speed was 25% of AP/Native .... they did get there with D3 on PC platforms, but Edge went to oblivion as an unfortunate blip on the radar. Had you opted for Seqoia, they had the people to make it work, and history would have been significantly changed. "

Ross remembers the major tragedy of EDGE which would never have happened had I been allowed to specify the system. At the time AWA/Sanderson (I can't remember the exact change name/date) were too busy with internal reorganisation to quote - actual statement to tender request for $250,000 system. Lionel Singer's mob tried to backdoor the quote. Ultimate was my preference but EDGE had personal directorial connections and Sequoia wasn't on the radar at that time..

However my Unix experience ranges across System V to Sun - the Sun was the biggest disaster as it went down for 10 days with a Unix virus, Pick was fine. The Edge was replaced with a Sanyo which I had also quoted and ran until 2000 - the brilliant accountants involved had extended my base system and their extensions were not 2000 compliant whereas I made ours compliant in 1988 and it is running to this day.

As for running like R83 well my code successfully incorporated the first remote credit card systems for Fuel sites in 1983 and I had service station pumps connected directly by 1988. We must acknowledge Luke Webber as assisting with the comms.. 

I fully agree that Raining Data dropped the ball by concentrating on Linux - ignoring the major desktop system in the world - which Ross has used extremely well. However we have used several different printing systems on everything from stand-alone PCs to remote virtual servers in cities and on base machines that I have no contact with. Our latest effort uses PrintWizard on Windows 7 and HP printers with many thousands of prints each month and nary an issue in three years ( touch wood). All has tested well on Windows 10.

Perhaps Ross has extended the definition of printing a tad too far :-)

As for corruptions I never had them even in the early Reality days. Use PROC properly, it is not a full blown operating language like BASIC, and Edit everything before you file it.

[TonyG Test]

David and Peter seem to be implying that Ross is asking too much of D3. Or that doing a full restore due to occasional frame loss is normal. I'd suggest the platform should work as advertised, and without issues that are not present in other platforms. Different sites exercise all of these platforms in different ways. We must acknowledge the experience of others. Rather than rebuking the bad experiences of others as potentially invalid, I think it's more appropriate to state that this has never happened in your own environment, but give a respectful nod to others who have actually had other experiences. I mean, there's a big difference between "no, the platform is fine, the other user was doing something wrong" and "it's good to know about issues that others have had in case we start doing something differently".

As to concentrating on Linux and ignoring the major desktop, um, would you prefer that they ignored the major server? This IS a server platform. D3 has never targeted one audience at the expense of another. In everything I've seen over the last 18 years, D3 has been given equal effort over both Windows and *nix. The focus on Linux might be misunderstood. Huge numbers of sites migrated from AIX, HP, and others to Linux to save operating costs. Other platforms went away (DG, SCO) and others weren't worth the effort to maintain the platforms. That leaves D3 being supported only over two Unix platforms, AIX and Linux. We only hear more about Linux because the number of sites far outweighs AIX.

That said, I encouraged Pick Systems to recognize the desktop as a huge opportunity, but it went nowhere. That wasn't instead of *nix, certainly not instead of positioning D3 Windows as a server environment, but in addition to these other traditional applications. I think the problem there is all about mindset, not technology. Most of us developers run over a single-user environment anyway, so there's certainly precedent to support that it works. The thing is getting people to recognize the platform for workstation use, that includes both the DBMS providers and the developer channel. I think that kind of thinking stopped when they moved away from D3 DOS. QM and OpenInsight (and even Caché) are more oriented to that industry. In fact, as I just said, since most of us run all of these platforms on a workstation we know that they all work, it's just that developers aren't seeing MV as a platform to support workstation applications. And really, I don't think QM or the others (except for OI) can or will ever really be positioned against tools like MS Access, SqlLite, or SQL Server Express for single-user databases. I think QM developers who came from R83 are still targeting server environments rather than going after workstations, where OI has been doing well in that space for a long time. With this we come back to the pricing model of MV, with most platforms selling for $100 to $500 per seat, intended for multiple users on a server. With that dinosaur of a model there's no way we can compete with other platforms.

As to concept of running in R83 mode, with the reply that D3 has been used in modern applications (fuel stations, etc). These are different things. You can keep D3 in R83 mode and do neat things with it. But that doesn't mean you're using the various tools that have been added from 1990-forward.

Sorry for being all over the map here... time to back away from the keyboard, get coffee, then come back and bang out some code.

T

[Peter McMurray]

Hi TG jumping to conclusions again best read the posts more carefully. I have the greatest respect for Ross Ferris software, unlike yourself as you refused to look at it, I actually use some of his work and am looking to use Visage in a possible development.

 

I have never had to do a restore for frames lost through printing or program generated GFEs and I would be annoyed if I did have to.

All my sites are multi-user not desktop singles however one does not need Windows server to run multi-user as Windows works great with D3. The concentration by Raining Data on Linux at the expense of Windows development was only overcome when John Bramley took charge.

This was a major drawback as there is no readily available Linux support outside of major cities - when I see moronic statements such as "I just roll a new kernel" , I am very annoyed at the thought of another client being left in the lurch when the programmer with his latest toy decides to go elsewhere.

Ross experience with Windows was bad mine is excellent however I had to lay off Unicode and associated development while RD got themselves sorted out. If Ross says there is a problem then I expect them to fix it ASAP however I would like more detail of how the problem arises. It may well be due to Ross's use of the VME versus the OSFI as he is the only person I have ever met that uses the Access exploding part control in the dictionary which is deprecated for the OSFI. Hopefully he will offer a deeper explanation but just as you like to be paid for work he may well see this issue falling in the same basket.

[David Knight]

Hi Tony,

I certainly did not mean to imply that. I've been thinking more about this over the past few days & trying to reconcile Ross' experience with mine and perhaps others like Pete. My hypothesis is that since both flavours of d3 are 'hosted' the differences are more likely to be o/s &/or h/w issues/differences; than inherent bugs with d3.

My reference to doing a vme restore because of lost frames was more about saying the frame loss were due to non-d3 issues such as users closing their telnet app before logging off, printer issues and network issues; rather than this being "normal". Of course it is not normal, and certainly should not be the case.

But my mobile phone drops out sometimes, too; requiring me to re-dial. It shouldn't do that either.

I have no doubt Ross has had problems, and those should be addressed. In regards to that, my experience via [the late] T-Data and specifically Mike Raffaele & Ross Reichardt [both of whom moved to their new Aussie owners, MBS] and their conduits back to engineering in d3 teams; has been excellent.

Perhaps Ross' issues are to do with the specific feature[s] which perhaps I do not use?

In that way, I do not consider myself to have been rebuking; but rather adding to the discussion to provide balance. Perhaps to the point of encouraging Ross to look again, although I know I would be unlikely to move off Windoze for my reasons; I suspect he is unlikely to move off *nix for his.

Cheers one and all.

[Tony Gravagno]

I don't know where to start here. As usual there is so much misunderstanding and misinformation that it's tough to get back to a base of reality before entering into the realm of agreement, disagreement, or an exchange of helpful information. So I'll just summarize.

1) John Bramley, best boss and most respected manager I've ever had, was VP of Engineering at Pick Systems before we made the switch to Raining Data.
2) While he's an excellent manager, engineer, etc, product direction has always been decided by higher level management in conjunction with Marketing and Sales. Technical departments do not determine which platform gets the focus.
3) There was never a higher priority of Linux over Windows. I don't doubt that this is your perception. But as former QA Manager and Product Manager, and now having been a customer of PS/RD/TL/RS for the last 15 years, I'm tell you I have never seen preferential treatment given to either of these platforms. The goal was Always to make All platforms work as best as possible.
4) You're confusing OSFI with FSI. Have I mentioned recently that I support Certification for "Value-Add" Resellers?
5) Frame loss has been a common issue in D3Windows for many years. TL/RS has done a lot in v9+ to fix that but it still happens once in a while. Terminated processes help to manifest the issue but that is not the only source of occasional frame leakage.
6) I don't know a single site that relies on local Linux support, as in "we're getting Linux, we should have a Linux guy nearby just in case". Sure, it's helpful to bring the local guy in when required but in the last 15 years I've never heard of a single case where this was actually a stated requirement or necessary. All Linux support that I've seen is done remotely. If you're that far out in the sticks where there is no ability to get network support, I'm guessing there is limited expertise for Windows out there as well, thus negating the relation between Linux and big cities.
7) "roll a new kernel"??  That's another one I've never heard from anyone in this industry, anyone doing application development, any end-user, or anyone outside of Linux fandom itself. "Rolling a kernel" would not be something that anyone does in a business environment, and it doesn't relate to anything we do in this industry.
8) "...client being left in the lurch..." ... and that doesn't happen with Windows or any other platform??

T

[Peter McMurray]

TG perhaps it is time that you listened instead of raging, as you said you have not worked there for the 15 years I was talking about.

In fact my statements re RD are all based on  information supplied by RD executives visiting Australia.

I am well aware of the difference between OSFI and FSI as I have posted here re printing with PrintWizard for example. I produce PDFs (OSFI) from FSI files using Basic which I then sort using FSI dictionaries and shoot out to multiple trays with different stationery and never lose a frame.

YOU may have never needed local Linux support. I must assume that you do not have remote customers in small towns. I have  customers in towns that are thousands of miles apart and can take two days to reach as often driving is the only option once one reaches a capital city. The computers are sourced locally and hardware support is invariably Microsoft only. Even that can go astray such as when, ten years ago, a junior tech destroyed D3 by installing updates without shutting it down. Now I ensure that techs and clients alike are on top of issues such as this.

The statement about rolling a new kernel came direct from this Pick group of people in a post not too long ago - perhaps in one of the previous discussion incarnations.

I note that you poopoo experience with credit cards and petrol pumps. Perhaps you are not experienced with interfacing machinery that runs its own interfaces rather than a standard operating system - I have never met another Pick supplier that had to carry his own line analysers and soldering gear often dealing with non standard interfaces such as the RS232 crap that Apple produced. Remote systems that I installed thirty years ago are still working despite the manufacturer having dropped support long ago. This necessitated learning how to deal with a wide range of telephone exchanges and tracing water faults in one case 60 miles away as well as explaining to other suppliers that credit card file interfaces from that time were not standard.

As for Unix experience I was experienced enough for the Comm Bank to fly me to Melbourne to sort out what was crashing their Pick system in Hobart. I cannot say that the client or HP was pleased when I found the fault that I became aware of a couple of years earlier when the Vic Human Services dept dumped HP for I qute " Falling off a cliff". Quite simply the HP RAID 50 could not handle high volume. Credit card data is distributed between banks daily with tens of thousands of transactions hitting the machine at once. The HP system coped for a few seconds then the RAid cache fell back in this instance to a steady one third of its peak but the HPUX just ceased multi tasking and other processes came to a virtual halt. Unfortunately the on line credit card systems have a 7 second time out and then try again which results in load going out exponentially. Better still I located a fault in the Pick software that treated a retry as a new transaction every fourth retry. When the IT head got charged 3 times for the groceries he was not pleased  :-)

[Ross Ferris]

On Tuesday, 24 November 2015 09:19:33 UTC+11, David Knight wrote:

Hi Tony,

I certainly did not mean to imply that. I've been thinking more about this over the past few days & trying to reconcile Ross' experience with mine and perhaps others like Pete. My hypothesis is that since both flavours of d3 are 'hosted' the differences are more likely to be o/s &/or h/w issues/differences; than inherent bugs with d3.

Your hypothesis is flawed. D3 on Linux & D3 on windows are 2 entirely different incarnations - the difference being the notion of the FSI introduced in the latter at a macro level, and who knows how different as you dig deeper. This "explains" why things that works in the VME fail in the FSI. If you (anyone) likes I can send you some programs that will bring a D3/Windows machine to it's knees - the same thing running on the same hardware (yeah, I do stuff like that!) under Linux & you wouldn't know the process was running

 

My reference to doing a vme restore because of lost frames was more about saying the frame loss were due to non-d3 issues such as users closing their telnet app before logging off, printer issues and network issues; rather than this being "normal". Of course it is not normal, and certainly should not be the case.

Simply using the spooler will "loose" frames from the VME with D3/Windows .... go ahead, try it. Take note of your FREE space in the VME. Write a little program that sends a 4K file to a printer as a HOLD entry -- (actually just 1 character will do the trick last time I checked) ... generate a few thousand entries, repeat a few times .... for i = 1 to 100 should do it, clearing the spooler out in between .... check your FREE space (& not a telnet drop in sight :-)

 

But my mobile phone drops out sometimes, too; requiring me to re-dial. It shouldn't do that either.

I have no doubt Ross has had problems, and those should be addressed. In regards to that, my experience via [the late] T-Data and specifically Mike Raffaele & Ross Reichardt [both of whom moved to their new Aussie owners, MBS] and their conduits back to engineering in d3 teams; has been excellent.

Ditto for most things .... but I'm talking about problems that Engineering have been aware of for at least a decade. Not to mention the strange runtime errors that will generate when you run flashed code & call flashed code long enough .... our "solution" is to reboot windows 

Perhaps Ross' issues are to do with the specific feature[s] which perhaps I do not use?

Maybe. We also do a lot of stuff with the OSFI - reading, writing & deleting OS levels files ... do you do much of that? Run flashed code? Use the native pick spooler

 

In that way, I do not consider myself to have been rebuking; but rather adding to the discussion to provide balance. Perhaps to the point of encouraging Ross to look again, although I know I would be unlikely to move off Windoze for my reasons; I suspect he is unlikely to move off *nix for his.

If you noted in one of my earlier posts you will see that I talked about possibly getting involved with the next BETA for D3/Windows - we already know that the current production release of D3/Windows has problems. I know there are many people that are happy with D3/Windows, but I'm not one of them .... and don't think about pointing to Windows as the culprit - UV on windows works just fine!

[Ross Ferris]

On Sunday, 22 November 2015 17:06:50 UTC+11, Peter McMurray wrote:

Ross Said

"IIRC your "unix" experience was with platforms like "Edge" -->  unproven platform running OA, and even on PC platforms OA was a dud that (quite rightly) I don't think Pick Systems ever sold in the wild --> speed was 25% of AP/Native .... they did get there with D3 on PC platforms, but Edge went to oblivion as an unfortunate blip on the radar. Had you opted for Seqoia, they had the people to make it work, and history would have been significantly changed. "

Ross remembers the major tragedy of EDGE which would never have happened had I been allowed to specify the system. At the time AWA/Sanderson (I can't remember the exact change name/date) were too busy with internal reorganisation to quote - actual statement to tender request for $250,000 system. Lionel Singer's mob tried to backdoor the quote. Ultimate was my preference but EDGE had personal directorial connections and Sequoia wasn't on the radar at that time..

However my Unix experience ranges across System V to Sun - the Sun was the biggest disaster as it went down for 10 days with a Unix virus, Pick was fine. The Edge was replaced with a Sanyo which I had also quoted and ran until 2000 - the brilliant accountants involved had extended my base system and their extensions were not 2000 compliant whereas I made ours compliant in 1988 and it is running to this day.

You know, I used to have all sorts of problems with early versions of WIndows (who didn't). Guess what .... it got better. Don't be too shocked, but the latest versions of D3 on Linux & AIX are a lot better than the bleeding edge technology you used 20-30 years ago, and I'd suggest that the D3/Linux & AIX platforms are "better" than R83 ever was 

As for running like R83 well my code successfully incorporated the first remote credit card systems for Fuel sites in 1983 and I had service station pumps connected directly by 1988. We must acknowledge Luke Webber as assisting with the comms.. 

I fully agree that Raining Data dropped the ball by concentrating on Linux - ignoring the major desktop system in the world - which Ross has used extremely well. However we have used several different printing systems on everything from stand-alone PCs to remote virtual servers in cities and on base machines that I have no contact with. Our latest effort uses PrintWizard on Windows 7 and HP printers with many thousands of prints each month and nary an issue in three years ( touch wood). All has tested well on Windows 10.

Perhaps Ross has extended the definition of printing a tad too far :-)

errm. No! Though to be fair we tend to NOT use the Pick spooler much these days, and we have clients that are producing (emailing, faxing & even producing real hard copies out of physical printers) thousands of forms a day.

I also agree that Pick Systems (right name for the company at the time) ignored the major desktop system in the world - initially WIndows 3.1, then Win 95 - and in the process marooned most developers to the same green screens that haunt us today. They tried to address the issues, but ultimately too little, to late (at the time) - and c'mon, are there any production sites of MVDisaster out there?

[David Knight]

Hi Ross,

Interesting so I thought I'd do a test based upon what you are saying:

"Simply using the spooler will "loose" frames from the VME with D3/Windows .... go ahead, try it. Take note of your FREE space in the VME. Write a little program that sends a 4K file to a printer as a HOLD entry -- (actually just 1 character will do the trick last time I checked) ... generate a few thousand entries, repeat a few times .... for i = 1 to 100 should do it, clearing the spooler out in between .... check your FREE space (& not a telnet drop in sight :-)"

Here was my process & my reasoning why. First I created a simple routine which is compiled [NB: NOT flashed, not catalogued, just a personal choice. Results may indeed differ if I flash; other can try...] Here is that code:

* Routine to test loss of frames

*

* Tests the assertion that hold entries cause loss of free frames

*  when deleted.

*

******************************************************************

* Main section

  * Create something to print

  TO.PRINT = ""

  FOR X = 1 TO 10             ;* Change to alter size of print

    TO.PRINT := "Z"

  NEXT X

  *

  * Get start value

  GOSUB GETFRAMES

  START.FRAMES = AVAIL.FRAMES

  *

  * Print to hold entry multiple times

  FOR X = 1 TO 100            ;* Change to alter number of hold entries

    EXECUTE "SP-ASSIGN HS" CAPTURING DUMMY RETURNING RETVAL

    PRINTER ON

    PRINT TO.PRINT

    PRINTER OFF

    PRINTER CLOSE

  NEXT X

  * Get fresh available value

  GOSUB GETFRAMES

  AFTER.FRAMES = AVAIL.FRAMES

  * Now clear the hold entries

  EXECUTE "SP-EDIT MUD" CAPTURING DUMMY RETURNING RETVAL

  END.FRAMES = AVAIL.FRAMES

  *

  GOTO ENDOFROUTINE

  *

******************************************************************

*

GETFRAMES:  * Get free frames via what command

  EXECUTE "WHAT (LSW" CAPTURING DUMMY RETURNING RETVAL

  *

  WHAT = DUMMY<3>

  WHAT = TRIM(WHAT)

  *

  AVAIL.FRAMES = FIELD(WHAT,' ',7)

  *

  RETURN

*

ENDOFROUTINE: * End of routine

  PRINT "FRAMES AT START OF ROUTINE: " : START.FRAMES

  PRINT "FRAMES AT END OF PRINT    : " : AFTER.FRAMES

  PRINT "FRAMES AT END OF ROUTINE  : " : END.FRAMES

  END

[I could of course have made it sexier by prompting for values, but to create alternate tests, change values and re-compile. Quick'n'dirty]

To fully test the assertion, I have to make sure the system is completely idle, no backgrounds, no phantoms, no other users. I make sure the spooler is empty. I start by logging off.

I then logon and get to TCL, and run a WHAT (WLS from TCL and note the value:

                                                           11:08:11 26 Nov 2015 

    memory  pibs   pcb0  sysbase/mod      maxfid  available  dfsize             

  4194303k    38    128     1271   7       63998      54701    4000             

I then RUN my program:

......

Hold Entry # 99                     

Hold Entry # 100                    

FRAMES AT START OF ROUTINE: 54679   

FRAMES AT END OF PRINT    : 54577   

FRAMES AT END OF ROUTINE  : 54577   

Note that the frames appear to have not yet been released....

Check again at TCL via WHAT (WLS

                                                           11:11:30 26 Nov 2015 

    memory  pibs   pcb0  sysbase/mod      maxfid  available  dfsize             

  4194303k    38    128     1271   7       63998      54690    4000             

Closer, but no cigar. So far, assertion appears true. But remember, d3 caches, so log off & back on again, repeat WHAT (WLS

                                                           11:13:11 26 Nov 2015 

    memory  pibs   pcb0  sysbase/mod      maxfid  available  dfsize             

  4194303k    38    128     1271   7       63998      54701    4000             

.... and the Frames are back. No loss of frames.

Now, I'm not trying to get into a pissing contest, or to prove I'm right, you're wrong etc; as I suspect there may well be a fault condition if I generate much larger files with much larger concurrent quantities of hold entries. But one also has to reasonable about one's testing. I mean while it matters academically if extreme cases cause a system to crack; but one also has to be pragmatic insofar as does this really happen at realistic levels in the real world for your app? I mean, do you really get concurrently thousands of 4k hold entries? 

For me, the test confirms what I suspect/know - I'm sure the frames would have been lost had this been a real-world example & instead of logging off neatly, I had closed my emulator thus breaking the telnet connection and thus destroying the PIB workspace, and possible 'dirty' frames waiting to be flushed & returned to the available pool. Of if the network had burped at that time causing a transient disconnect; or some other ABNORMAL issue. I guess that then leads to a dissertation on whether d3 should recover elegantly from such situations, and maybe that's true; but that's not we are discussing here. I have had "discussions" with non-mv IT people who when cornered into having to admit there was a network card/hub/driver/power/whatever glitch say "well 'xyz' doesn't have a problem with that". Which to me says that their argument is that a system such as 'xyz' is obviously aware of the limitations and builds their system to handle the inefficiencies of the underlying sub-system. To me, that's backwards thinking. d3 relies upon the functionality of it's host. Always has. Sure there have been bugs, but imho for the most part, the practical, serious ones get dealt with over time, and the product is now very stable. Perfect? Probably not.

Enough from me, I'm sounding argumentative, & I do not mean to be...

BTW: just tried flashing it and results are the same [well in fact the routine released one more frame before I had to log off, which is a good thing, so technically flashed performed better than non-flashed!] insofar as the net frames remained at 54701 in my example.

I recommend others do the same test, too and see what happens on your system.

[You may need to alter the GETFRAMES sub to pull out the correct value for your system].

HTH....

Again, I'm not saying your experience is invalid; obviously it is ... I'm just saying the cause may not be what you think it is; because others do not have the same experience as you.

Oh, and to answer your questions: It is true, I do not do much with OSFI [I do some]; and I [currently] use little flashed code, although that is changing as I move away from SB+

I hope this contrinutes to the dialogue.

Cheers!

[Ross Ferris]

David,

I appreciate the fact that you wrote a test program to test my statement - and you are right, in the real world you would end up with print jobs of various sizes, some a single frame, others hundreds or thousands of frames, and over time, frames do go missing.

You may well be right, and there other factors at play, though RD always acknowledged this as a spooler issue

We DO make extensive use of flashed code (speed is good) ... one of those "new features" that too few people use to have all of the kinks worked out

[Tony Gravagno]

David, I'd suggest that if the problem were easily reproducible that it would not be something that would bother Ross for years, as RD/TL/RS would be able to issue a quick patch. But it is cool that you wrote a test.

Also, I don't believe you provided your D3 release, which is critical in discussions like this. RS has made great strides in elimination of frame loss and I believe they were quite pleased with the minimal-to-no loss that they achieved in v9.2. I don't know what the status of this is in their eyes, whether the issue appears to be resolved or whether they still feel they need to find a new culprit to address in v10.

HTH
T

[David Knight]

Fair enough. Version used in test: d3/win v9.2.1 on W10, fully patched

True, but it was Ross' assertion that such a simple test would demonstrate [& I quote] "fatal flaws". Again, not having a go; just suggesting the 'problem' may not be as fatal as described, or perhaps associated with other elements not specifically d3; as my experience and that of others is not the same as his.

I gave the source in the hope others on other versions may feel inclined to repeat the test and post their results. Maybe someone has an older live version of d3/nt or d3/win?

I'm not saying d3 is perfect, better or worse; it is my personal favourite though. I have also had my own set of 'weird'. Here's one for you, currently proven, reproducible and sitting with engineering:

If one has an active select-list containing >1 item and one is doing a LIST-LABEL command using any dictionary items; the system fails [falls into debug or creates a runaway if I recall] but only if you are using PIB 3!!! Totally, completely and absolutely bizarre! I may have the precise details wrong as it was a few months back & I've put it out of my mind.

Cheers!

[Peter McMurray]

Hi

I have been tied up checking out a flat file switch from Cobol crazy fixed format to csv for Excel. When will people learn that Excel has a 15 digit limit on numbers, you cannot send a 16 digit credit card number direct into Excel but 12345678-12345678 will work fine. Of course major international companies no so much better than a little guy in Tasmania. Sure I can work around it in D3 unless somebody brings it up in Excel first and says yes to change.  OOPS card number wrong.

Anyway I have run the tests as Ross suggested. I first did a VME restore so that I knew where I was starting.

I was able to vary the frames a few just by logging on as DM or myself.

I ran a massive print job and cleared it actually winning back a couple of frames that I seemed to have lost in the different logons.

I then ran a program to produce 100 prints of 1000 lines.

SP-EDIT MUD got everything back to scratch.

It seems that one can apparently lose a couple of frames out of 55,000 and then win them back again. After several resets and reruns I seem to be six frames down on my start point. However over many years of running D3 on Windows this apparent loss has never built up to being a problem as I was totally unaware of it. Yes I would like it fixed  and it does seem that whatever MUD does can affect the result. However as Ross pointed out Windows is a totally different beast to Linux and as I mentioned Windows comes last - see the release plan for Unicode if you don't believe me.

The issue of  flash run time errors is something I have never experienced. In fact it was Ross who brought the addition of the LIST-RUNTIME-ERRORS to my attention many years ago. Thanks mate, I always use it when I run new code and occasionally double check once released into the wild.

I was a slow adopter of Flash because it was all or nothing for me. I have a master control program and all code runs as subroutines. However Flash has worked fine for years now.

As they say in the states, and as Ross has shown YMMV however I do not feel that it is a big enough issue to stop using the platform based on my style of coding which does not involve a lot of external code as Ross Visage product may do. My OSFI is limited to importing/exporting files, all prints, and calling things like Adobe Acrobat.

My tests today were run on Windows 10 fully up to date

:which
                    System Release Information
                    ==========================
     D3 Release Version  9.2.1.WINDOWS

     Implementation. . . . . . WINDOWS
     Software Serial Number. . 11031377
     System ID Number  . . . . 70348075
     Release . . . . . . . . . D3
     Windows Information . . . Windows;pick0;6.2.9200;;6.2
:free
Disk Available

0....1....2....3....4....5....6....7....8....9....100%
********************************************

                                   MB             Bytes        Frames
Maximum disk space     100%       256       255,992,000        63,998
System usage             4%        10         9,804,000         2,451
Data usage              10%        25        25,480,000         6,370
Available disk space    86%       221       220,708,000        55,177
:

[Rick Weiser]

Holy crap!!

I didn't think this post would ever cause this much damage.

Rick

[Ross Ferris]

That IS the problem D3/Windows

[Peter McMurray]

Ah Yes Ross! Windows 100% consistent world wide with guaranteed support anywhere or Unix/Linux/Aix/Nom Du Jour with more versions than Kardashian has outfits and zero support in the under 50 user workplace.. Please remind me of the problem again :-)