ShellExecuteEx example
in [Visual Studio]
|
Prev: Disk Imaging Utility
Next: MSComm and a Scanner
From: Shell on 1 Dec 2006 14:44 In response to the post: On Fri, 01 Dec 2006 08:18:20 GMT, erewhon(a)nowhere.uk (J French) stated...and I replied: >>If you're interested I'll tell you about the time I won a bet over a >>computer (Univac 1000/74) that would run a program with differing >>results depending on the workload. I was told "A computer can never >>run a program differently from one time to the next"...I proved him >>wrong. <g> oops, that was Univac 1100, not 1000 > >I'm interested - please do. On Univac 1100/2200 systems they have an environment called TIP (Transaction Interface Processing) that simulates a conversational session (they call it sudo-conversational). It is the environment where the DMS and DPS processes are used (Data Management System and Display Processing System). The DMS system requires a pre-compiler pass to insert the proper calls to the Database system. Well, in the early days of DMS development (around 1984) it was discovered that if you placed a DMS command (Get, Put, Open...) inside an If statement, the results would be erronious. Sometimes it would work, other times it would fail. What we found out is that the If statement starts a timer, and if the If statement wasn't completed within the time allotted it would "drop out" and move on. With a call to DMS in there, the If was failing when the call didn't return in time. So, to fix the problem we put the DMS command alone in a paragraph, then performed it from the If. When a "Perform" (Like the GoSub of Basic) is processed, the If timer is paused until the perform is complete. Problem solved. Back then I was always doing things in an unorthodox way...like the time I developed a batch report generator using QLP (an early version of SQL that was like driving a tank in a bicycle race) from the TIP environment. TIP transactions were only allowed to run 30 octal seconds, so I had to find a way to generate the batch process and start it outside of TIP. I had a guy from Univac call me to find out how I did it! lol Oh, excuse me, by then Sperry Univac was being called Unisys. Shell
From: J French on 2 Dec 2006 03:02 On Fri, 01 Dec 2006 19:44:57 GMT, Shell <drshell(a)mindspring.com> wrote: <snip> >Well, in the early days of DMS development (around 1984) it was >discovered that if you placed a DMS command (Get, Put, Open...) inside >an If statement, the results would be erronious. Sometimes it would >work, other times it would fail. What we found out is that the If >statement starts a timer, and if the If statement wasn't completed >within the time allotted it would "drop out" and move on. With a call >to DMS in there, the If was failing when the call didn't return in >time. So, to fix the problem we put the DMS command alone in a >paragraph, then performed it from the If. When a "Perform" (Like the >GoSub of Basic) is processed, the If timer is paused until the perform >is complete. Problem solved. That sounds like a complete nightmare - I can see the reason for the timeout but it sounds like On Error Resume Next with no error checking
From: Shell on 2 Dec 2006 13:41 In response to the post: On Sat, 02 Dec 2006 08:02:15 GMT, erewhon(a)nowhere.uk (J French) stated...and I replied: >On Fri, 01 Dec 2006 19:44:57 GMT, Shell <drshell(a)mindspring.com> >wrote: > ><snip> > >>Well, in the early days of DMS development (around 1984) it was >>discovered that if you placed a DMS command (Get, Put, Open...) inside >>an If statement, the results would be erronious. Sometimes it would >>work, other times it would fail. What we found out is that the If >>statement starts a timer, and if the If statement wasn't completed >>within the time allotted it would "drop out" and move on. With a call >>to DMS in there, the If was failing when the call didn't return in >>time. So, to fix the problem we put the DMS command alone in a >>paragraph, then performed it from the If. When a "Perform" (Like the >>GoSub of Basic) is processed, the If timer is paused until the perform >>is complete. Problem solved. > >That sounds like a complete nightmare >- I can see the reason for the timeout >but it sounds like On Error Resume Next with no error checking Remember, this was on a mainframe system with time-sharing. So everthing, more or less, had to be limited to allow for an environment where everyone has a fair share...on second thought that was dumb! Then there was the time I crashed the system by issuing an Operator command from a remote terminal. The Ops console receives unsolicited requests from devices. Like an "Out of Paper" request from a printer. Once the Operator fills the need, the request is answered...usually with the indicator to continue printing. In my case I had issued a request to "Down" a disc pack (As project lead it was my pack, and I was exclusive user of it). The terminal where I issued the command came back with a "Possible fatal result" request, which normally means that if you continue with the command a program will abort. After double checking that no programs where running on my project, I replied with the continue response and the system never came back from it. Like having the power go out...all the things you would normally not notice suddenly get quieter. I called the computer room and told them I'd crashed the system (the guy I spoke to was a well known friend and I laugh every time I think of it). He said, "No way! You could not have crashed it...wait a minute, maybe you did!". We found out two things that evening. First, that the system had been using that pack...Duh! And that the system allowed unsolicited requests to be sent to remote terminals. The latter lesson was quickly fixed and never happened again. @@CONS was never the same ;) Shell
From: J French on 3 Dec 2006 06:19
On Sat, 02 Dec 2006 18:41:18 GMT, Shell <drshell(a)mindspring.com> wrote: >In response to the post: > On Sat, 02 Dec 2006 08:02:15 GMT, erewhon(a)nowhere.uk (J French) >stated...and I replied: > >>On Fri, 01 Dec 2006 19:44:57 GMT, Shell <drshell(a)mindspring.com> >>wrote: <snip> >>That sounds like a complete nightmare >>- I can see the reason for the timeout >>but it sounds like On Error Resume Next with no error checking >Remember, this was on a mainframe system with time-sharing. So >everthing, more or less, had to be limited to allow for an environment >where everyone has a fair share...on second thought that was dumb! Nicely put >Then there was the time I crashed the system by issuing an Operator >command from a remote terminal. The Ops console receives unsolicited >requests from devices. Like an "Out of Paper" request from a printer. >Once the Operator fills the need, the request is answered...usually >with the indicator to continue printing. In my case I had issued a >request to "Down" a disc pack (As project lead it was my pack, and I >was exclusive user of it). The terminal where I issued the command >came back with a "Possible fatal result" request, which normally means >that if you continue with the command a program will abort. >After double checking that no programs where running on my project, I >replied with the continue response and the system never came back from >it. Like having the power go out...all the things you would normally >not notice suddenly get quieter. I called the computer room and told >them I'd crashed the system (the guy I spoke to was a well known >friend and I laugh every time I think of it). He said, "No way! You >could not have crashed it...wait a minute, maybe you did!". >We found out two things that evening. First, that the system had been >using that pack...Duh! And that the system allowed unsolicited >requests to be sent to remote terminals. The latter lesson was >quickly fixed and never happened again. >@@CONS was never the same ;) I developed the file locking for our company, it was about 1987 on earlyish Novell - about 5:30 pm I would set of a load of machines hammering away and leave them for about half an hour. Around 1:30 am the network would mysteriously go down, after a few instances we spotted the correlation - but never figured out exactly why it was happening. |