INFO-VAX Wed, 25 Jul 2007 Volume 2007 : Issue 403 Contents: Re: datatrieve Re: Debugging shareable images weirdness Dynamically set VMS "environment" settings from a program? Re: Dynamically set VMS "environment" settings from a program? Re: Dynamically set VMS "environment" settings from a program? Re: Dynamically set VMS "environment" settings from a program? RE: Dynamically set VMS "environment" settings from a program? Re: Dynamically set VMS "environment" settings from a program? RE: Dynamically set VMS "environment" settings from a program? Re: Dynamically set VMS "environment" settings from a program? RE: Dynamically set VMS "environment" settings from a program? RE: Dynamically set VMS "environment" settings from a program? Re: IBM advertises mainframe OS - whither VMS? Re: July the 4th Re: July the 4th Re: July the 4th Re: Show Expansion slots Re: What OS version to run on a DEC 3000-M600 ---------------------------------------------------------------------- Date: 24 Jul 2007 13:00:05 -0500 From: briggs@encompasserve.org Subject: Re: datatrieve Message-ID: In article , clarence writes: > > I need to modify the fifth element of a field that is defined with an > occurs clause. How do I do that? As I recall, there is no "array indexing" technique available in Datatrieve. So you have to fake it. I'm about ten years out of practice, so forgive any errors: declare occurs-count usage long. for r in your-domain where r.some-field = "some value" modify using begin occurs-count = 0 for o in your-occurs-clause modify using begin occurs-count = occurs-count + 1; if occurs-count eq 5 then o.field-in-your-occurs-clause = "new value"; end end ------------------------------ Date: Tue, 24 Jul 2007 20:00:23 -0500 From: Chris Scheers Subject: Re: Debugging shareable images weirdness Message-ID: <5gnll8F3hfdsqU1@mid.individual.net> VAXman- @SendSpamHere.ORG wrote: > In article , John Reagan writes: >> >> VAXman- @SendSpamHere.ORG wrote: >> >>> * The Alpha uses a PALcode to implement the BPT. I don't have the IA64 >>> instruction manual before me but it too has a similar mechanism. >>> >> The Itanium has an instruction called "break" that takes a literal >> argument. One of those literal values has been reserved for breakpoint. >> To set a breakpoint, the debugger rewrites the appropriate bundle with >> a break instruction in one of the slots. > > I knew there was an instruction but I did not recall the specifics as > to whether it was a whole bundle supplanted or just an instruction in > the bundle. > > Generally, it needs to modify the instruction stream as with the Alpha > and the VAX. It's been a long time since I looked (VMS V5 time-frame?), but IIRC, if it is necessary to set a breakpoint in a global page, DEBUG makes a private, process local copy of the page and sets the breakpoint there. I don't remember if DEBUG does this explicitly or if the creation of the local copy is a side effect of changing the protection on the page. I also don't remember what happens if the page is a global, writable page. (The thought of such a page containing code is not comforting.) Note that this was for the VAX. I have not checked the mechanism for Alpha or Itanium. -- ----------------------------------------------------------------------- Chris Scheers, Applied Synergy, Inc. Voice: 817-237-3360 Internet: chris@applied-synergy.com Fax: 817-237-3074 ------------------------------ Date: Tue, 24 Jul 2007 21:12:19 -0500 From: "Paul Raulerson" Subject: Dynamically set VMS "environment" settings from a program? Message-ID: <003601c7ce61$3acd4870$b067d950$@com> Ah HAH! I have at last figured out something that will be elementary to you folks, but has annoyed the living daylights out of me for a week now. :) Take a typical (green screen) program, it puts up a header at the top of the screen, body text, a function key line and a message line at the bottom. Okay, this is more IBM that perhaps VMS green screen programs are normally setup to be, but hey- I have not SEEN any VMS green screen programs other than the editors, and *they* can use function keys! I even figured out how to get into "USER-MODE" and stay there, but for the life of me, function keys insist on doing weird and strange things - like causing an interrupt when I hit F6 for example. But I finally found the magic incantation that takes care of *that* problem... one need only perform a set term/NOLINE_EDITING and voila! The doggone function keys work as expected. (From Putty, with VT400 keys set, and using /DEVICE_TYPE=VT400_SERIES in the set term command...) Problem is, it actually does turn off terminal editing, and I *LIKE* terminal editing! So I would like to dynamically turn this feature OFF when a program starts, and then turn it back ON when the program exits. How might I go about doing this? In particular from COBOL? Thanks -Paul P.S. It is okay to refer me to the correct manual; I have searched all through the COBOL manuals and I suspect I did not recognize what I am looking for. -Paul ------------------------------ Date: Tue, 24 Jul 2007 21:22:36 -0500 From: David J Dachtera Subject: Re: Dynamically set VMS "environment" settings from a program? Message-ID: <46A6B3EC.334B9B2F@spam.comcast.net> Paul Raulerson wrote: > > Ah HAH! I have at last figured out something that will be elementary to you > folks, but has annoyed the living daylights out of me for a week now. :) > > Take a typical (green screen) program, it puts up a header at the top of the > screen, body text, a function key line and a message line at the bottom. > Okay, this is more IBM that perhaps VMS green screen programs are normally > setup to be, but hey- I have not SEEN any VMS green screen programs other > than the editors, and *they* can use function keys! > > I even figured out how to get into "USER-MODE" and stay there, but for the > life of me, function keys insist on doing weird and strange things - like > causing an interrupt when I hit F6 for example. > > But I finally found the magic incantation that takes care of *that* > problem... one need only perform a set term/NOLINE_EDITING and voila! The > doggone function keys work as expected. (From Putty, with VT400 keys set, > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > Problem is, it actually does turn off terminal editing, and I *LIKE* > terminal editing! So I would like to dynamically turn this feature OFF when > a program starts, and then turn it back ON when the program exits. > > How might I go about doing this? In particular from COBOL? > > Thanks > -Paul > > P.S. It is okay to refer me to the correct manual; I have searched all > through the COBOL manuals and I suspect I did not recognize what I am > looking for. -Paul I believe a cruise through the documentation of the SMG$ RTL routines may be helpful. Otherwise, you may need to figure out how to invoke $QIO with the proper parameters/flags to make the change(s). Dunno fer sure... -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 25 Jul 2007 02:41:17 -0000 From: ian.s.burgess@gmail.com Subject: Re: Dynamically set VMS "environment" settings from a program? Message-ID: <1185331277.699322.17760@x35g2000prf.googlegroups.com> On Jul 25, 12:12 pm, "Paul Raulerson" wrote: > Ah HAH! I have at last figured out something that will be elementary to you > folks, but has annoyed the living daylights out of me for a week now. :) > > Take a typical (green screen) program, it puts up a header at the top of the > screen, body text, a function key line and a message line at the bottom. > Okay, this is more IBM that perhaps VMS green screen programs are normally > setup to be, but hey- I have not SEEN any VMS green screen programs other > than the editors, and *they* can use function keys! > > I even figured out how to get into "USER-MODE" and stay there, but for the > life of me, function keys insist on doing weird and strange things - like > causing an interrupt when I hit F6 for example. > > But I finally found the magic incantation that takes care of *that* > problem... one need only perform a set term/NOLINE_EDITING and voila! The > doggone function keys work as expected. (From Putty, with VT400 keys set, > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > Problem is, it actually does turn off terminal editing, and I *LIKE* > terminal editing! So I would like to dynamically turn this feature OFF when > a program starts, and then turn it back ON when the program exits. > > How might I go about doing this? In particular from COBOL? > > Thanks > -Paul > > P.S. It is okay to refer me to the correct manual; I have searched all > through the COBOL manuals and I suspect I did not recognize what I am > looking for. -Paul Paul, Calling LIB$DO_COMMAND from Cobol seems like an easy option. Ian ------------------------------ Date: Wed, 25 Jul 2007 11:02:24 +0800 From: "Richard Maher" Subject: Re: Dynamically set VMS "environment" settings from a program? Message-ID: Hi Paul, Can't you just use DCL to turn it off before running the image and turn it back on when DCL is returned to? Otherwise I imagine someone (other than me :-) knows the bit to set in the terminal driver. See the I/O Reference Manual. (Pretty usefull book all round) Cheers Richard Maher. PS. If it makes you feel better Firefox and Internet Explorer have completely different ideas as to which keys should be trapped by the browser and which should be made available to your JavaScript. If you look at the enter() function in my t3$examples:queue_lookup.html example you will see what you have to do not to echo non-numeric characters in a numeric field and to stop IE from using as Firefox allows you to trap a whole lot more function keys than IE does. "David J Dachtera" wrote in message news:46A6B3EC.334B9B2F@spam.comcast.net... > Paul Raulerson wrote: > > > > Ah HAH! I have at last figured out something that will be elementary to you > > folks, but has annoyed the living daylights out of me for a week now. :) > > > > Take a typical (green screen) program, it puts up a header at the top of the > > screen, body text, a function key line and a message line at the bottom. > > Okay, this is more IBM that perhaps VMS green screen programs are normally > > setup to be, but hey- I have not SEEN any VMS green screen programs other > > than the editors, and *they* can use function keys! > > > > I even figured out how to get into "USER-MODE" and stay there, but for the > > life of me, function keys insist on doing weird and strange things - like > > causing an interrupt when I hit F6 for example. > > > > But I finally found the magic incantation that takes care of *that* > > problem... one need only perform a set term/NOLINE_EDITING and voila! The > > doggone function keys work as expected. (From Putty, with VT400 keys set, > > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > > > Problem is, it actually does turn off terminal editing, and I *LIKE* > > terminal editing! So I would like to dynamically turn this feature OFF when > > a program starts, and then turn it back ON when the program exits. > > > > How might I go about doing this? In particular from COBOL? > > > > Thanks > > -Paul > > > > P.S. It is okay to refer me to the correct manual; I have searched all > > through the COBOL manuals and I suspect I did not recognize what I am > > looking for. -Paul > > I believe a cruise through the documentation of the SMG$ RTL routines may be > helpful. Otherwise, you may need to figure out how to invoke $QIO with the > proper parameters/flags to make the change(s). Dunno fer sure... > > -- > David J Dachtera > dba DJE Systems > http://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Page > http://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page: > http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page: > http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page: > http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 24 Jul 2007 22:39:05 -0500 From: "Paul Raulerson" Subject: RE: Dynamically set VMS "environment" settings from a program? Message-ID: <004501c7ce6d$5a469240$0ed3b6c0$@com> > -----Original Message----- > From: ian.s.burgess@gmail.com [mailto:ian.s.burgess@gmail.com] > Sent: Tuesday, July 24, 2007 9:41 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Dynamically set VMS "environment" settings from a program? > > On Jul 25, 12:12 pm, "Paul Raulerson" wrote: > > Ah HAH! I have at last figured out something that will be elementary > to you > > folks, but has annoyed the living daylights out of me for a week now. > :) > > > > Take a typical (green screen) program, it puts up a header at the top > of the > > screen, body text, a function key line and a message line at the > bottom. > > Okay, this is more IBM that perhaps VMS green screen programs are > normally > > setup to be, but hey- I have not SEEN any VMS green screen programs > other > > than the editors, and *they* can use function keys! > > > > I even figured out how to get into "USER-MODE" and stay there, but > for the > > life of me, function keys insist on doing weird and strange things - > like > > causing an interrupt when I hit F6 for example. > > > > But I finally found the magic incantation that takes care of *that* > > problem... one need only perform a set term/NOLINE_EDITING and voila! > The > > doggone function keys work as expected. (From Putty, with VT400 keys > set, > > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > > > Problem is, it actually does turn off terminal editing, and I *LIKE* > > terminal editing! So I would like to dynamically turn this feature > OFF when > > a program starts, and then turn it back ON when the program exits. > > > > How might I go about doing this? In particular from COBOL? > > > > Thanks > > -Paul > > > > P.S. It is okay to refer me to the correct manual; I have searched > all > > through the COBOL manuals and I suspect I did not recognize what I am > > looking for. -Paul > > Paul, > > Calling LIB$DO_COMMAND from Cobol seems like an easy option. > > Ian Ah Ian - you are a genius. DO_COMMAND does the job, but it terminates the cotton picking executable that calls it. However, LIB$SPAWN works just great to do the same thing, with the advantage I don't have to clean up on the way out - the setting appears to be held only through execution of the main program. :) Thanks -Paul In the most simple form, the call is: 77 WS-USER-COMMAND PIC X(127) VALUE SPACES. .. .. .. CALL "LIB$SPAWN" USING BY DESCRIPTOR WS-USER-COMMAND ------------------------------ Date: Wed, 25 Jul 2007 12:01:12 +0800 From: "Richard Maher" Subject: Re: Dynamically set VMS "environment" settings from a program? Message-ID: Hi Paul, This from page 193: - TT2$M_EDIT Terminal edit. This characteristic is set by the SET TERMINAL command for all terminals that support ANSI-defined advanced editing functions. These functions include the ability to insert or delete a line and the ability to insert or delete characters in an existing line. Terminals with this characteristic are a superset of TT2$M_DECCRT. Appendix Clists the valid escape sequences for terminals with the TT2$M_EDIT characteristic. You $assign a channel to the terminal then call $qio io$_setmode to toggle it and then $dassgn before exit to be neat. I can't swear that the above works (and I'd do it for you if I wasn't trying to prove a buffer overrun stack-corrupter with Multinet's io$_acpcontrol inetacp$c_trans inetacp_func$c_gethostbyaddr ) but it sounds about right. > Ah Ian - you are a genius. DO_COMMAND does the job, but it terminates the > CALL "LIB$SPAWN" > USING BY DESCRIPTOR WS-USER-COMMAND If you're happy with that then great, but mate it's not the Sufi way! (Well not the VMS way anyway :-) Cheers Richard Maher PS: Was it AOS/VS that used to spawn a process to do everything? "Paul Raulerson" wrote in message news:004501c7ce6d$5a469240$0ed3b6c0$@com... > > > > -----Original Message----- > > From: ian.s.burgess@gmail.com [mailto:ian.s.burgess@gmail.com] > > Sent: Tuesday, July 24, 2007 9:41 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: Dynamically set VMS "environment" settings from a program? > > > > On Jul 25, 12:12 pm, "Paul Raulerson" wrote: > > > Ah HAH! I have at last figured out something that will be elementary > > to you > > > folks, but has annoyed the living daylights out of me for a week now. > > :) > > > > > > Take a typical (green screen) program, it puts up a header at the top > > of the > > > screen, body text, a function key line and a message line at the > > bottom. > > > Okay, this is more IBM that perhaps VMS green screen programs are > > normally > > > setup to be, but hey- I have not SEEN any VMS green screen programs > > other > > > than the editors, and *they* can use function keys! > > > > > > I even figured out how to get into "USER-MODE" and stay there, but > > for the > > > life of me, function keys insist on doing weird and strange things - > > like > > > causing an interrupt when I hit F6 for example. > > > > > > But I finally found the magic incantation that takes care of *that* > > > problem... one need only perform a set term/NOLINE_EDITING and voila! > > The > > > doggone function keys work as expected. (From Putty, with VT400 keys > > set, > > > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > > > > > Problem is, it actually does turn off terminal editing, and I *LIKE* > > > terminal editing! So I would like to dynamically turn this feature > > OFF when > > > a program starts, and then turn it back ON when the program exits. > > > > > > How might I go about doing this? In particular from COBOL? > > > > > > Thanks > > > -Paul > > > > > > P.S. It is okay to refer me to the correct manual; I have searched > > all > > > through the COBOL manuals and I suspect I did not recognize what I am > > > looking for. -Paul > > > > Paul, > > > > Calling LIB$DO_COMMAND from Cobol seems like an easy option. > > > > Ian > > > Ah Ian - you are a genius. DO_COMMAND does the job, but it terminates the > cotton picking executable that calls it. > However, LIB$SPAWN works just great to do the same thing, with the advantage > I don't have to clean up on the way out - the setting appears to be held > only through execution of the main program. :) > > Thanks > -Paul > > In the most simple form, the call is: > 77 WS-USER-COMMAND PIC X(127) VALUE SPACES. > .. > .. > .. > CALL "LIB$SPAWN" > USING BY DESCRIPTOR WS-USER-COMMAND > > ------------------------------ Date: Tue, 24 Jul 2007 23:14:35 -0500 From: "Paul Raulerson" Subject: RE: Dynamically set VMS "environment" settings from a program? Message-ID: <000001c7ce72$50a32050$f1e960f0$@com> I'll be looking up the TT2$M_EDIT call, because I suspect you can many other things with it I really like doing, But this is working for tonight and my eyes are insisting on closing... another day tomorrow! -Paul > -----Original Message----- > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com] > Sent: Tuesday, July 24, 2007 11:01 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Dynamically set VMS "environment" settings from a program? > > Hi Paul, > > This from page 193: - > > TT2$M_EDIT Terminal edit. This characteristic is set by the SET > TERMINAL > command for all terminals that support ANSI-defined advanced > editing functions. These functions include the ability to insert or > delete a line and the ability to insert or delete characters in an > existing line. Terminals with this characteristic are a superset of > TT2$M_DECCRT. Appendix Clists the valid escape sequences for > terminals with the TT2$M_EDIT characteristic. > > You $assign a channel to the terminal then call $qio io$_setmode to > toggle > it and then $dassgn before exit to be neat. > > I can't swear that the above works (and I'd do it for you if I wasn't > trying > to prove a buffer overrun stack-corrupter with Multinet's > io$_acpcontrol > inetacp$c_trans inetacp_func$c_gethostbyaddr ) but it sounds about > right. > > > Ah Ian - you are a genius. DO_COMMAND does the job, but it terminates > the > > > CALL "LIB$SPAWN" > > USING BY DESCRIPTOR WS-USER-COMMAND > > If you're happy with that then great, but mate it's not the Sufi way! > (Well > not the VMS way anyway :-) > > Cheers Richard Maher > > PS: Was it AOS/VS that used to spawn a process to do everything? > > "Paul Raulerson" wrote in message > news:004501c7ce6d$5a469240$0ed3b6c0$@com... > > > > > > > -----Original Message----- > > > From: ian.s.burgess@gmail.com [mailto:ian.s.burgess@gmail.com] > > > Sent: Tuesday, July 24, 2007 9:41 PM > > > To: Info-VAX@Mvb.Saic.Com > > > Subject: Re: Dynamically set VMS "environment" settings from a > program? > > > > > > On Jul 25, 12:12 pm, "Paul Raulerson" wrote: > > > > Ah HAH! I have at last figured out something that will be > elementary > > > to you > > > > folks, but has annoyed the living daylights out of me for a week > now. > > > :) > > > > > > > > Take a typical (green screen) program, it puts up a header at the > top > > > of the > > > > screen, body text, a function key line and a message line at the > > > bottom. > > > > Okay, this is more IBM that perhaps VMS green screen programs are > > > normally > > > > setup to be, but hey- I have not SEEN any VMS green screen > programs > > > other > > > > than the editors, and *they* can use function keys! > > > > > > > > I even figured out how to get into "USER-MODE" and stay there, > but > > > for the > > > > life of me, function keys insist on doing weird and strange > things - > > > like > > > > causing an interrupt when I hit F6 for example. > > > > > > > > But I finally found the magic incantation that takes care of > *that* > > > > problem... one need only perform a set term/NOLINE_EDITING and > voila! > > > The > > > > doggone function keys work as expected. (From Putty, with VT400 > keys > > > set, > > > > and using /DEVICE_TYPE=VT400_SERIES in the set term command...) > > > > > > > > Problem is, it actually does turn off terminal editing, and I > *LIKE* > > > > terminal editing! So I would like to dynamically turn this > feature > > > OFF when > > > > a program starts, and then turn it back ON when the program > exits. > > > > > > > > How might I go about doing this? In particular from COBOL? > > > > > > > > Thanks > > > > -Paul > > > > > > > > P.S. It is okay to refer me to the correct manual; I have > searched > > > all > > > > through the COBOL manuals and I suspect I did not recognize what > I am > > > > looking for. -Paul > > > > > > Paul, > > > > > > Calling LIB$DO_COMMAND from Cobol seems like an easy option. > > > > > > Ian > > > > > > Ah Ian - you are a genius. DO_COMMAND does the job, but it terminates > the > > cotton picking executable that calls it. > > However, LIB$SPAWN works just great to do the same thing, with the > advantage > > I don't have to clean up on the way out - the setting appears to be > held > > only through execution of the main program. :) > > > > Thanks > > -Paul > > > > In the most simple form, the call is: > > 77 WS-USER-COMMAND PIC X(127) VALUE SPACES. > > .. > > .. > > .. > > CALL "LIB$SPAWN" > > USING BY DESCRIPTOR WS-USER-COMMAND > > > > > ------------------------------ Date: Wed, 25 Jul 2007 00:30:29 -0400 From: JF Mezei Subject: Re: Dynamically set VMS "environment" settings from a program? Message-ID: Paul Raulerson wrote: > Take a typical (green screen) program, it puts up a header at the top of the > screen, body text, a function key line and a message line at the bottom. > Okay, this is more IBM that perhaps VMS green screen programs are normally > setup to be, but hey- I have not SEEN any VMS green screen programs other > than the editors, and *they* can use function keys! You mentioned COBOL. Cobol has a screen generator. If you look at the cobol documentation, you can design a screen in the working storage section (with line and column values for each piece of text) and then if I recall, use the ACCEPT statement to get the information. Or, you can use old packages such as FMS which provide more full screen display control and PF keys etc. But FMS still requires some additional licence. There are lower level routines others have alluded to (SMG$ routines) which are used by the higher level software such as COBOL, FMS etc. If you are looking for something like TSO/SPF (ISPF or whatever it is called this week), then ALLIN1 (office server) gives you this type of funtionality. (It is based on FMS but gives you a high level interface to menus, displays, access to indexed files etc). ------------------------------ Date: Wed, 25 Jul 2007 00:06:09 -0500 From: "Paul Raulerson" Subject: RE: Dynamically set VMS "environment" settings from a program? Message-ID: <000001c7ce79$83ceeed0$8b6ccc70$@com> Yes, thank you. I'm using the COBOL screens right now in an effort to tame the cost to the potential users. Terminal emulation for green screen users under VMS is - somewhat more difficult that anything else. I was under the impression AllInOne was more like an office software product than anything remotely similar to ISPF. (Which has been named ISPF for a few decades now... :) I actually like the FORMS panel editor and development system, but I am quite impressed with how capable the COBOL system is. It isn't easy to do things like save screens (since you cannot command the terminal to send you a full dump of the screen) and telnet/ssh is not as smooth as I would like, but it is still relatively fast and I am getting to the point were a software port looks like it will be doable. I'll probably sanitize a small application and post it up free in the hopes of getting constructive criticism. Little things like field editing are eating my lunch right and left. No guaranteed DELETE key that actually does what a DELETE key is supposed to do, for instance. I might have to guarantee the software only on a PC with specific emulation software or something, which I really don't like. The alternative is to target a really standard terminal emulation, like 3270 emulation, and write a convertor and TCP daemon to handle the communications. I would rather not though, if I can avoid it. I will take a look at All in One if I can find the install image for it somewhere. -Paul > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: Tuesday, July 24, 2007 11:30 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Dynamically set VMS "environment" settings from a program? > > Paul Raulerson wrote: > > Take a typical (green screen) program, it puts up a header at the top > of the > > screen, body text, a function key line and a message line at the > bottom. > > Okay, this is more IBM that perhaps VMS green screen programs are > normally > > setup to be, but hey- I have not SEEN any VMS green screen programs > other > > than the editors, and *they* can use function keys! > > > You mentioned COBOL. Cobol has a screen generator. If you look at the > cobol documentation, you can design a screen in the working storage > section (with line and column values for each piece of text) and then > if > I recall, use the ACCEPT statement to get the information. > > Or, you can use old packages such as FMS which provide more full screen > display control and PF keys etc. But FMS still requires some additional > licence. > > There are lower level routines others have alluded to (SMG$ routines) > which are used by the higher level software such as COBOL, FMS etc. > > If you are looking for something like TSO/SPF (ISPF or whatever it is > called this week), then ALLIN1 (office server) gives you this type of > funtionality. (It is based on FMS but gives you a high level interface > to menus, displays, access to indexed files etc). ------------------------------ Date: Wed, 25 Jul 2007 00:09:05 -0500 From: "Paul Raulerson" Subject: RE: Dynamically set VMS "environment" settings from a program? Message-ID: <000101c7ce79$ecd2ef80$c678ce80$@com> Yes, thank you. I'm using the COBOL screens right now in an effort to tame the cost to the potential users. Terminal emulation for green screen users under VMS is - somewhat more difficult than anything else. I was under the impression AllInOne was more like an office software product than anything remotely similar to ISPF. (Which has been named ISPF for a few decades now... :) I actually like the FORMS panel editor and development system, but I am quite impressed with how capable the COBOL system is. It isn't easy to do things like save screens (since you cannot command the terminal to send you a full dump of the screen) and telnet/ssh is not as smooth as I would like, but it is still relatively fast and I am getting to the point where a software port looks like it will be doable. I'll probably sanitize a small application and post it up free in the hopes of getting constructive criticism. Little things like field editing are eating my lunch right and left. No guaranteed DELETE key that actually does what a DELETE key is supposed to do, for instance. I might have to guarantee the software only on a PC with specific emulation software or something, which I really don't like. The alternative is to target a really standard terminal emulation, like 3270 emulation, and write a convertor and TCP daemon to handle the communications. I would rather not though, if I can avoid it. I will take a look at All in One if I can find the install image for it somewhere. -Paul > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: Tuesday, July 24, 2007 11:30 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Dynamically set VMS "environment" settings from a program? > > Paul Raulerson wrote: > > Take a typical (green screen) program, it puts up a header at the top > of the > > screen, body text, a function key line and a message line at the > bottom. > > Okay, this is more IBM that perhaps VMS green screen programs are > normally > > setup to be, but hey- I have not SEEN any VMS green screen programs > other > > than the editors, and *they* can use function keys! > > > You mentioned COBOL. Cobol has a screen generator. If you look at the > Cobol documentation, you can design a screen in the working storage > section (with line and column values for each piece of text) and then > if > I recall, use the ACCEPT statement to get the information. > > Or, you can use old packages such as FMS which provide more full screen > display control and PF keys etc. But FMS still requires some additional > license. > > There are lower level routines others have alluded to (SMG$ routines) > which are used by the higher level software such as COBOL, FMS etc. > > If you are looking for something like TSO/SPF (ISPF or whatever it is > called this week), then ALLIN1 (office server) gives you this type of > functionality. (It is based on FMS but gives you a high level interface > to menus, displays, access to indexed files etc). ------------------------------ Date: 24 Jul 2007 17:40:07 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: IBM advertises mainframe OS - whither VMS? Message-ID: In article <7f659$46a648e6$cef89c18$25412@TEKSAVVY.COM-Free>, "John Smith" writes: > > Page 29 of the July 16, 2007 issue of Information Week > > It's a full-page ad for secure solutions. > > www.ibm.com/takebackcontrol/security Since we _are_ talking about _security_, the URL would be: http://www.ibm.com/software/info/takebackcontrol/us/nonflash/security/index.jsp ------------------------------ Date: 24 Jul 2007 18:59:20 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: July the 4th Message-ID: <5gn0g8F3hi5b4U1@mid.individual.net> In article , david20@alpha2.mdx.ac.uk writes: > > Of course the war had to be won. (But the war in Iraq was won just as > decisively as the war against Germany and Japan. It was the lack of planning > for the aftermath that was different.) It had nothing to do with planing and everything to do with politics. When we defeated Germany we "occupied" the country. And we were the sole legal authority until it was deemed they were ready to re-enter world civilization. In Iraq we have never been allowed to exercise full control. That's why we still see people (supposed non-combatanta) celebrating things like weddings by shooting guns into the air. There should be no guns in Iraq except in the hands of American soldiers and anyone else seen with one should be considered a target. But, the ROE do not allow for that. So, when you see a man (or a woman for that matter) waving a gun in public, you can't shoot at him. Of course, later on today he may don a mask and shoot at Americans. If the military were allowed to handle Iraq like we handled Germany and Japan they may not be a democracy yet but at least the violence would have ended. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Jul 2007 19:05:02 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: July the 4th Message-ID: <5gn0quF3hi5b4U2@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , JF Mezei writes: >> >> It failed because the USA military insisted it remain 100% in charge >> wherever it operates. > > If the US Military was 100% in charge there wouldn't be anyone else > running around Iraq with guns. There has never been enough troops > commited to make that so and I doubt there ever will be. Actually, there are and have been more than enough troops to do the job. What is lacking is permission. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Tue, 24 Jul 2007 18:21:02 -0700 From: AEF Subject: Re: July the 4th Message-ID: <1185326462.528678.294640@19g2000hsx.googlegroups.com> On Jul 24, 12:59 pm, JF Mezei wrote: > Bob Koehler wrote: > > If the US Military was 100% in charge there wouldn't be anyone else > > running around Iraq with guns. There has never been enough troops > > commited to make that so and I doubt there ever will be. > > The USA domestic political issues are more or less irrelevant here. > Whether they have enough resources on the ground in Iraq or not is not > the issue. The issue is that the USA military is the one that makes the > decisions in Iraq. It is USA military policy that USA military answers > to nobody but itself when abroad. (aka: USA would not send troups on a > mission that was not lead by an american). What does this have to do with that? Anyway, the alternative to us being "in charge" is all-out civil war. As it is they're blowing up funerals!!! How low can you go? > It was the USA military that decided to change the iraqi currency (to > make hussein and sons poor), it was the USA military that decided which > books could and could not be used at schools, and which teachers could > and could not teach, which person could and could not run for election > etc. The decision to allow US oil firms to buy into Iraqi oil fields > didn't come from Iraqis. Sounds like most of this would be an improvement if true. > Now, put yourself into Iraqi shoes. The USA are factually inept at > keeping peace in Iraq, inept at rebuilding, and very good are corruption > and excesses when it comes to feeding Haliburton and Blackwater, and the > USA military remains in power, with a puppet government in Iraq that is > there to put an Iraqi face to US decisions that benefit USA corporations > instead of benefiting iraqis. Depends if you were on Saddam's good side or not. Tough choice for many. > You don't make peace with machine guns. You make peace by meeting with > the people who oppose you and include them in the rebuilding process. > But the USA military (unexpectedly) only thinks about military solutions. Hmmm. I don't think this works when they're shooting at you. Remember the beheadings? > Under Hussein, if you were law abiding and didn't openly criticise him, > you were safe. There was a functioning government, well defined election Ha ha ha ha ha! You don't recall his sons randomly shooting people who happened to be within range? You don't remember the slaughter of Shiites after the first Iraq war? You're speaking total nonsense. > process and constitution that may have needed just a bit of tweaking to > ensure no elected leader becomes a lifelong dictator. It didn't need He WAS lifelong dictator!!! He always got 99% of the vote? Do you seriously believe that free people voted this way? > THAT much tweaking to get it to an acceptable level of respect for human > rights and proper democracy. And there was a (fragile) balance between Oh, it just gets better and better. Tweaking a brutal dictatorship to achieve proper democracy? Please attach a breathalyzer to your computer. > the various sects. During the 1990s, peace between Hussein and the Kurds > was achieved by granting the Kurds greater autonomy and ensuring that > the military in the kurd region was staffed and lead by kurds. He killed thousands of them with chemical weapons!!! > > Why did the USA insist on zapping the currency, military and police, > banking system and constitution and starting from scratch ? What? Start with a Saddam constitution? He actually had a constitution worth more than the paper it was written on? > > The problem is that the very mentality that caused those catastrophic > mistakes is still very much in place because the military is still very > much in control. This is total nonsense. Yes, this is a disaster. Yes the US screwed up, but not as much as you have with your analysis! > What is neededd is for the USA to relegate troups to simple policing and > not interfere with the government AT ALL, and let he UN and he Arab > League help/guide the government. But that would require the USA > military to take orders from the Iraqi government which is something the > USA military is genetically incapable of doing. So as a result, the > deaths, carnage an civil war continue. I'm done. Others have commented on this. AEF ------------------------------ Date: Tue, 24 Jul 2007 15:16:50 -0700 From: "Tom Linden" Subject: Re: Show Expansion slots Message-ID: On Tue, 24 Jul 2007 14:46:10 -0700, Richard B. Gilbert wrote: > IanMiller wrote: >> ANAL/SYS >> CLUE CONFIG >> may give some hints >> IIRC The ES45 model 2 has 10 slots. >> > > And if it follows the pattern of the ES40, the model 1 will have about > three slots! > 6. 3 on top, 4 blocked out and 3 on the bottom -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Wed, 18 Jul 2007 12:26:44 -0500 From: Slor Subject: Re: What OS version to run on a DEC 3000-M600 Message-ID: Thanks guys for all the feedback. -- James http://www.e-host-direct.com Reliable web hosting from $12/year. ------------------------------ End of INFO-VAX 2007.403 ************************