Hi Paul,

"933B" looks strange. As someone else already suggested, you need to create
a log file with $MC LMCP. The other thing you need to do is look for this
logical: - DECDTM$INHIBIT and if it's set to true then set it to false and
re-run the startup. You won't need the XG startup as that's for the XA
Gateway which is only of interest if you want your RMS updates controlled by
some sort of XA monitor like Tuxedo. (The XA Veneer on the other hand (that
doesn't need a seperate process) is useful if you want to update Orrible
Oracle on VMS in the same 2PC as your Rdb, RMS (and possibly Windows SQL
Server) databases.

I still don't know why people persist in saying that VAX COBOL does not
support commit/rollback verbs when the pointer to the docs that I posted
previous seems to show that it does? No matter; now that I know what you're
doing I'm intrigued!

I love VMS (always will) I love seeing stuff ported to VMS; the more the
better! Having said that, who the hell is giving you funding for this crap?
Keep it on IBM and just change the incontinence nappies every now and then
(works for VMS engineering :-)

OK we are where we are: - What database exactly was the COBOL talking to on
IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not knowing
anything at all about IBM) that all the CICS stuff used precompilers and had
EXEC-SQL in the code everywhere.

What about all the JCL? How do you intend to backup your data? You may have
RUJ functionality but what about AIJ functionality and roll forward to point
in time? Does it get distributed anywhere? Data wharehouses?

Look I'm sure you thought all this through and I wish you well, but if you
want cheap, leave it on IBM. If you want to do it right then re-write it on
VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving ,
oligarchic gravy-train that is currently running it into the buffers.

Cheers Richard Maher

PS. Here's a web site where you can often hear from Jim Johnson if you miss
him, and can also reminisce about what it was like to be in a living
development environment: -

http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1

Digital had it way back when :-(

PPS> There used to be an RPG II compiler on PDPs don't know if it ever made
it to VMS.

"Paul Raulerson" wrote in message
news:000301c7e532$25d7be90$71873bb0$@com...
>
> [SNIP SNIP SNIP]
> > -----Original Message-----
> > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> > Sent: Wednesday, August 22, 2007 6:11 PM
> > To: Info-VAX@Mvb.Saic.Com
> > Subject: Re: COBOL Transactions?
> >
> [SNIP]
>
> Hey Richard, do you have a pointer to how to turn this DDTM *on*?
> I have found:
> DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
> DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
> DECDTM$STARTUP.COM;1
>
> and ran the DECDTM$STARTUP.com script, which seems to have succeeded. Also
> ran the DDTM$XG_START_SERVER.com
> script, and they *seem* to be running.
>
> Marked a test file with SET FILE/RU_JOURNAL and it seems to report itself
> correctly.
>
> Constantly get back a failure code, 933B.
>
> Ran the example script, created the files and still get the same error
code.
> I do not know if it is a license thing or not. Show license finds the
> following lines, so I think it is licensed.
>
> DTM DEC 0 0 100 0.0 (none)
> 31-JUL-2008
> RMSJNL DEC 0 0 100 0.0 (none)
> 31-JUL-2008
>
> I cannot find any startup files or stuff with *RMS* in the name to run or
> whatever.
>
> I did scan through the manuals I could find, and the RMS Journal manual
was
> clear that DECdtm has to be
> running first, but ... not really working. Advice? Pointers?
Thanks -Paul
>
>

On 08/22/07 23:37, Paul Raulerson wrote:
>
>> -----Original Message-----
>> From: Hein RMS van den Heuvel [mailto:heinvandenheuvel@gmail.com]
>> Sent: Wednesday, August 22, 2007 10:50 PM
>> To: Info-VAX@Mvb.Saic.Com
>> Subject: Re: COBOL Transactions?
[snip]
>> Hmm, those remarks suggest very limited understanding of how OpenVMS
>> works.
>> Languages do NOT roll their own stuff. They are all just dialects to
>> do the same thing using core functions from the kernel or run time
>> libraries.
>> If Pascal had 'free' transaction management, then Cobol and Fortran
>> and Basic would also have it. Period. That's how it's done for
>> OpenVMS.
>>
>
> Not so.

You've got two (three?) months of VMS experience, and you're telling
*us* how VMS languages are?

Slightly arrogant and foolish.

> COBOL is not COBOL unless it supplies certain indexed file handling
> capabilities, something that is NOT true of other languages. Part of the
> normal COBOL thing

Normal in the VS/COBOL world, maybe...

> is to supply the BEGIN TRANSACTION keywords, though it is
> not required in the language spec for COBOL 85.

"CALL DTM$START_TRANSACTION()." isn't that complicated of a change
to your code.

> I believe it is for the new
> spec coming out...

Then if VMS COBOL 3.0 decides to follow the latest standard, it'll
have BEGIN TRANSACTION.

> Of course, high end transaction systems handle this very well, usually by
> serializing
> access to file resources, and by providing true transaction. They cost
> though-
> CICS for example runs anywhere from just under a thousand dollars per month
> *up*.

ACMS serves the same purpose in VMS.

[snip]

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
wrote:

> Not so. COBOL is not COBOL unless it supplies certain indexed file
> handling
> capabilities, something that is NOT true of other languages. Part of the
> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
> it is
> not required in the language spec for COBOL 85. I believe it is for the
> new
> spec coming out...

Indexed file handling is in the PL/I semantics.


--
PL/I for OpenVMS
www.kednos.com

On 08/23/07 08:25, Tom Linden wrote:
> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
> wrote:
>
>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>> handling
>> capabilities, something that is NOT true of other languages. Part of the
>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>> it is
>> not required in the language spec for COBOL 85. I believe it is for
>> the new
>> spec coming out...
>
> Indexed file handling is in the PL/I semantics.

Yeah, but anyone in his right mind knows that PL/1 sucks.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

On Aug 22, 11:03 pm, "Paul Raulerson" wrote:
> [SNIP SNIP SNIP]>
>
> Constantly get back a failure code, 933B.

That's not a failure code in OpenVMS, but it is a bad informational.
It should possibly translate to '%SYSTEM-I-NEWBIE, Beginner in action"

'get back' FROM WHAT? In which field?

The Cobol should look like:

START-TRANS.
CALL "SYS$START_TRANSW" USING omitted, omitted, BY REFERENCE
IOSB,
omitted, omitted, omitted, omitted, omitted, omitted
GIVING STS.
:

The other place to check for status is after the open of a file marked
for RU.
Typically that would involve something like

DECLARATIVES.
ERROR-HANDLER SECTION.
USE AFTER STANDARD EXCEPTION PROCEDURE ON THE-FILE.
HERE-WE-GO.
MOVE RMS-STS TO STS.
MOVE RMS-STV TO STV.
DISPLAY "File status ", FILE-STATUS, " STS=", STS, " STV=",
STV.
END DECLARATIVES.

hth,
Hein.



>
> Ran the example script, created the files and still get the same error code.
> I do not know if it is a license thing or not. Show license finds the
> following lines, so I think it is licensed.
>
> DTM DEC 0 0 100 0.0 (none)
> 31-JUL-2008
> RMSJNL DEC 0 0 100 0.0 (none)
> 31-JUL-2008
>
> I cannot find any startup files or stuff with *RMS* in the name to run or
> whatever.
>
> I did scan through the manuals I could find, and the RMS Journal manual was
> clear that DECdtm has to be
> running first, but ... not really working. Advice? Pointers? Thanks -Paul

In article <1187840978.421774.183940@z24g2000prh.googlegroups. com>, Hein RMS van den Heuvel writes:
> On Aug 22, 1:53 pm, "Paul Raulerson" wrote:
>> I posted this question in another, but I figured someone here might
>> have a good idea they were willing to share.
>>
>> Most COBOL implementations provide a
>> BEGIN TRANSACTION
>> COMMIT/ROLLBACK
>> construct.

>> Or if John R. is reading this - any plans to add transaction management directly into the compiler? Or is there transaction management built into Pascal or Fortran that I can use to manage this?
>
> Hmm, those remarks suggest very limited understanding of how OpenVMS
> works.
> Languages do NOT roll their own stuff. They are all just dialects to
> do the same thing using core functions from the kernel or run time
> libraries.
> If Pascal had 'free' transaction management, then Cobol and Fortran
> and Basic would also have it. Period. That's how it's done for
> OpenVMS.

If that Cobol syntax is standardized (a question not answered to date
in this discussion), VMS Cobol should support it by calling RMS Journaling
from the generated code.

This is analogous to HP Ada automatically calling DECthreads to support
Ada tasking.

Hi Paul,

Anyone know what this is good for: -
http://h71000.www7.hp.com/doc/82fina...0.html#ref_661

And here's one that inserts a row into the Rdb MF_PERSONNEL database in the
same ACID-proof 2PC as a client that is inserting a row into the
NORTHWIND.employee table on Windows2000, Commit them all or roll them all
back! (You might find the error handling useful, and you would use
start_trans instead of start_branch)

Cheers Richard Maher

PS. The caps-lock key is on the left.

************************************************** **************************
********
*
*
* COPYRIGHT (c) TIER3 SOFTWARE LTD. ALL RIGHTS RESERVED.
*
*
*
* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY *
* IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF SUCH LICENSE AND WITH
THE *
* THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY
OTHER *
* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO
ANY *
* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS
HEREBY *
* TRANSFERRED.
*
*
*
* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND *
* SHOULD NOT BE CONSTRUED AS A COMMITMENT BY TIER3 SOFTWARE LTD.
*
*
*
************************************************** **************************
********
identification division.
program-id. tip_init.
data division.
working-storage section.
01 ss$_debug pic s9(9) comp value external
ss$_debug.
01 ss$_abort pic s9(9) comp value external
ss$_abort.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp value external
ss$_normal.
*
01 syi_item_list.
03 item_nodename.
05 pic s9(4) comp value 6.
05 pic s9(4) comp value external
syi$_nodename.
05 pointer value
reference local_node.
05 pointer value
reference local_node_len.
03 pic s9(9) comp.
*
01 syi_iosb.
03 syi_cond pic s9(9) comp.
03 pic x(4).
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
01 debug_on pic x(1).
01 debug_commands.
03 cmd_len pic x(1) value x"25".
03 pic x(37) value "set
language cobol; show process/full".
*
01 sqlcode pic s9(9) comp.
01 db_spec.
03 pic x(20) value "alias
pers filename".
03 db_filename pic x(30) value
"mf_personnel".
*
01 rdb$message_vector external.
03 rdb$lu_num_arguments pic s9(9) comp.
03 rdb$lu_status pic s9(9) comp.
03 rdb$alu_arguments occurs 18 times.
05 rdb$lu_arguments pic s9(9) comp.
*
linkage section.
01 t3_system_name pic x(8).
01 t3_buffer_size pic 9(9) comp.
procedure division using t3_system_name, t3_buffer_size giving sys_status.
00.
*+
* To assist a run-time decision as to whether or not to invoke debug
* TIER3 has defined a local DCL symbol T3$DEBUG. This symbol is set
* to the value specified by the system manager in the Tier3 Configuration
* file ie: "Y" or "N".
*-
call "lib$get_symbol" using by descriptor "T3$DEBUG", debug_on giving
sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.

if debug_on = "Y"
call "lib$signal"
using by value ss$_debug, 1
by reference debug_commands.

move t3_system_name to system_name.
move t3_buffer_size to buffer_size.

call "sys$getsyiw"
using by value 0, 0, 0
by reference syi_item_list, syi_iosb
by value 0, 0
giving sys_status.
if sys_status = ss$_normal move syi_cond to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*+
* Connect to the database to make sure it's there and for 1st query
performance.
*-
call "declare_connection_name" using sqlcode, db_spec.
if sqlcode not = zeros
call "sys$putmsg" using rdb$message_vector
call "lib$stop" using by value ss$_abort.

call "t3$setctx" using demo_context giving sys_status.
if sys_status not = ss$_normal go to fini.
*
fini.
exit program.
*
end program tip_init.
identification division.
program-id. tip_logon.
data division.
working-storage section.
01 t3$k_decnet pic s9(9) comp value external
t3$k_decnet.
01 t3$k_tcp_ip pic s9(9) comp value external
t3$k_tcp_ip.
01 lib$_strtru pic s9(9) comp value external
lib$_strtru.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp value external
ss$_normal.
*
01 remote_node_name pic x(31).
01 remote_user_name pic x(12).
01 remote_user_socket redefines remote_user_name.
03 remote_host_addr.
05 rha_1 pic x.
05 rha_2 pic x.
05 rha_3 pic x.
05 rha_4 pic x.
03 remote_port_num pic 9(9) comp.
*
01 tcpip_rem_user_len pic 9(4) comp.
01 tcpip_rem_user pic x(21).
*
linkage section.
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
01 transport_type pic 9(4) comp.
*
01 remote_node_desc pic x(8).
*
01 remote_user_desc pic x(8).
*
01 local_user_desc.
03 lud_class_len.
05 lud_len pic 9(4) comp.
05 lud_class pic 9(4) comp.
03 lud_addr pic 9(9) comp.
*
01 local_persona pic 9(9) comp.
*
procedure division using demo_context,
transport_type,
remote_node_desc,
remote_user_desc,
local_user_desc,
local_persona giving sys_status.
00.
call "lib$scopy_dxdx"
using by reference remote_node_desc
by descriptor remote_node_name
giving sys_status.
if sys_status not = ss$_normal and lib$_strtru go to fini.

call "lib$scopy_dxdx"
using by reference remote_user_desc
by descriptor remote_user_name
giving sys_status.
if sys_status not = ss$_normal and lib$_strtru go to fini.

call "lib$scopy_dxdx"
using by reference local_user_desc
by descriptor session_user
giving sys_status.
if sys_status not = ss$_normal go to fini.
*+
* Report the client association in the execution server's log file.
*-
display "Association with ", session_user(1:lud_len), " established".
display "Transport = " transport_type with conversion.
display "Rem node = " remote_node_name.
display "Rem user = " no advancing.

evaluate transport_type
when t3$k_decnet display remote_user_name
when t3$k_tcp_ip call "sys$fao"
using by descriptor
"!@UB.!@UB.!@UB.!@UB:!ZL"
by reference
tcpip_rem_user_len
by descriptor
tcpip_rem_user
by reference rha_1,
rha_2, rha_3, rha_4
by value
remote_port_num
giving sys_status
if sys_status not = ss$_normal go to fini
end-if
display tcpip_rem_user(1:tcpip_rem_user_len)
end-evaluate.

call "t3$persona_assume" giving sys_status.
*
fini.
exit program.
*
end program tip_logon.
identification division.
program-id. tip_recv.
data division.
working-storage section.
01 out_msg pointer value external
out_msg.
01 ddtm$m_nowait pic 9(9) comp value external
ddtm$m_nowait.
01 ddtm$_aborted pic 9(9) comp value external
ddtm$_aborted.
01 t3$m_close pic 9(9) comp value external
t3$m_close.
01 t3$m_now pic 9(9) comp value external
t3$m_now.
01 t3$m_more pic 9(9) comp value external
t3$m_more.
01 t3$m_oob pic 9(9) comp value external
t3$m_oob.
01 t3$_chanclose pic 9(9) comp value external
t3$_chanclose.
01 ss$_abort pic 9(9) comp value external
ss$_abort.
01 ss$_normal pic 9(9) comp value external
ss$_normal.
01 sys_status pic 9(9) comp.
*
01 sqlcode pic 9(9) comp.
01 rdb$message_vector external.
03 rdb$lu_num_arguments pic 9(9) comp.
03 rdb$lu_status pic 9(9) comp.
03 rdb$alu_arguments occurs 18 times.
05 rdb$lu_arguments pic 9(9) comp.
*
01 sql_ctx.
03 pic 9(9) comp value 1.
03 pic 9(9) comp value 1.
03 pic 9(9) comp value 16.
03 db_tid pic x(16).
03 pic 9(9) comp.
*
01 tip_tid pic x(16).
01 tip_bid pic x(16).
*
01 dtm_iosb.
03 dtm_iosb_status pic 9(4) comp.
03 pic x(2).
03 reason_code pic 9(9) comp.
*
01 tip_tm_url_rec.
03 pic xx value "11".
03 tip_tm_url_len pic 9(4) comp.
03 tip_tm_url pic x(128).
*
01 abort_msg pic x(255).
01 out_len pic 9(4) comp.
01 comp_status.
03 pic x(2) value "22".
03 commit_flag pic x(1).
*
linkage section.
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
01 msg_buff.
03 msg_type pic x(2).
03 pic x(508).

01 update_bal_msg redefines msg_buff.
03 pic x(2).
03 dept_name pic x(30).
03 tip_txn_url pic x(256).
*
01 msg_size pic s9(9) comp.
*
01 msg_flags pic s9(9) comp.
*
procedure division
using demo_context,
msg_buff,
msg_size,
msg_flags
giving sys_status.
kick_off section.
00.
evaluate msg_type
when "10" perform get_tm_url
when "20" perform update_account_bal_push
when other move ss$_abort to sys_status
end-evaluate.

if sys_status = t3$_chanclose move ss$_normal to sys_status.

exit program.
*
get_tm_url section.
00.
call "t3$tip_get_tm_url"
using by descriptor tip_tm_url
by reference tip_tm_url_len
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.

add 4 to tip_tm_url_len giving out_len.
call "t3$send"
using by reference tip_tm_url_rec
by value out_len, t3$m_close
giving sys_status.
*
update_account_bal_push section.
00.
call "t3$tip_url_to_tid"
using by descriptor tip_txn_url of update_bal_msg(1msg_size -
32))
by reference tip_tid, tip_bid
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.

call "sys$start_branchw"
using by value 0, 0
by reference dtm_iosb
by value 0, 0
by reference tip_tid
by descriptor local_node(1:local_node_len)
by reference tip_bid
giving sys_status.
if sys_status = ss$_normal move dtm_iosb_status to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
move tip_tid to db_tid.
perform the_update.
*
call "t3$send"
using by reference comp_status
by value 3, t3$m_close
giving sys_status.
if sys_status = t3$_chanclose
move "N" to commit_flag
else
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status.

if commit_flag = "Y"
perform commit_trans
else perform abort_trans.
*
fini.
*
the_update section.
00.
call "set_trans_rw" using sqlcode, sql_ctx.
if rdb$lu_status not = ss$_normal
call "sys$putmsg" using rdb$message_vector
call "lib$stop" using by value ss$_abort.

call "update_dept" using sqlcode, dept_name, sql_ctx.
if rdb$lu_status not = ss$_normal
move "N" to commit_flag
call "sys$putmsg"
using by reference rdb$message_vector
by value out_msg, 0, 0
giving sys_status
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status
end-if
else
move "Y" to commit_flag.
*
fini.
*
commit_trans section.
00.
call "sys$end_branchw"
using by value 0, 0
by reference dtm_iosb
by value 0, 0
by reference tip_tid, tip_bid
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
if dtm_iosb_status = ss$_abort
if reason_code not = zeros
call "sys$getmsg"
using by value reason_code
by reference out_len
by descriptor abort_msg
by value 0,0
giving sys_status
if sys_status not = ss$_normal
call "lib$stop" using by value sys_status
end-if
display "Couldn't commit - " abort_msg (1ut_len)
end-if
else
if dtm_iosb_status not = ss$_normal
call "lib$stop" using by value dtm_iosb_status.
*
abort_trans section.
00.
call "sys$abort_transw"
using by value 0, ddtm$m_nowait
by reference dtm_iosb
by value 0, 0
by reference tip_tid
by value ddtm$_aborted
by reference tip_bid
giving sys_status.
if sys_status = ss$_normal move dtm_iosb_status to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
end program tip_recv.
identification division.
program-id. tip_logoff.
data division.
working-storage section.
01 iss$c_id_natural pic 9(9) comp value external
iss$c_id_natural.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp.
*
linkage section.
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
procedure division using demo_context giving sys_status.
00.
display "Session completed with user ", session_user.
move spaces to session_user.

call "sys$persona_assume" using iss$c_id_natural, omitted giving
sys_status.
*
fini.
exit program.
*
end program tip_logoff.
identification division.
program-id. tip_fini.
data division.
working-storage section.
01 ss$_abort pic s9(9) comp value external
ss$_abort.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
*
01 sqlcode pic s9(9) comp.
*
01 rdb$message_vector external.
03 rdb$lu_num_arguments pic s9(9) comp.
03 rdb$lu_status pic s9(9) comp.
03 rdb$alu_arguments occurs 18 times.
05 rdb$lu_arguments pic s9(9) comp.
*
linkage section.
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
procedure division using demo_context giving ss$_normal.
00.
display "Execution server shutting down".

call "disconnect_db" using sqlcode
if sqlcode not = zeros
call "sys$putmsg" using rdb$message_vector
call "lib$stop" using by value ss$_abort.

exit program.
*
end program tip_fini.
identification division.
program-id. tip_int.
data division.
working-storage section.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 link_lost pic x(1) value x"01".
*
linkage section.
*
01 demo_context.
03 system_name pic x(8).
03 buffer_size pic 9(9) comp.
03 local_node pic x(6).
03 local_node_len pic 9(4) comp.
03 session_user pic x(12).
03 persona_context pic 9(9) comp.
*
01 interrupt_msg pic x(16).
*
01 interrupt_type pic 9(9) comp.
88 system_msg value external
t3$k_system.
88 user_msg value external
t3$k_user.
*
procedure division
using demo_context,
interrupt_msg,
interrupt_type
giving ss$_normal.
00.
if (system_msg and interrupt_msg(1:1) = link_lost)
display "Link to client has been lost".

exit program.
*
end program tip_int.
identification division.
program-id. out_msg.
*+
* Send Rdb error messages back for output in VB-Net message window.
*-
data division.
working-storage section.
*+
* If you're using DECnet you can initialize send_flags =

* TIER3 will tell DECnet to group your messages so that your client
application
* receives a single record. (TCP/IP is obviously stream oriented)
*-
01 send_flags pic 9(9) comp value external send_flags.
01 t3$m_now pic 9(9) comp value external t3$m_now.
01 t3$_chanclose pic 9(9) comp value external
t3$_chanclose.
01 ss$_abort pic 9(9) comp value external ss$_abort.
01 ss$_normal pic 9(9) comp value external ss$_normal.
01 sys_status pic 9(9) comp.
*+
* Intel and Alpha are same endian so just send it as an integer.
*-
01 reply_hdr.
03 error_id pic xx value "88".
03 error_len pic 9(4) comp.
*
linkage section.
*
01 msg_desc.
03 msg_len pic 9(4) comp.
03 msg_class pic 9(4) comp.
03 msg_addr pointer.
*
procedure division using msg_desc giving ss$_abort.
00.
move msg_len to error_len.

call "t3$send" using reply_hdr by value 4, send_flags giving sys_status.
if sys_status = ss$_normal
call "t3$send"
using by value msg_addr, msg_len, t3$m_now
giving sys_status.

if sys_status not = t3$_chanclose and ss$_normal
call "lib$stop" using by value sys_status.
*
fini.
exit program.
*
end program out_msg.

"Richard Maher" wrote in message
news:fajppt$4g0$1@news-01.bur.connect.com.au...
> Hi Paul,
>
> "933B" looks strange. As someone else already suggested, you need to
create
> a log file with $MC LMCP. The other thing you need to do is look for this
> logical: - DECDTM$INHIBIT and if it's set to true then set it to false and
> re-run the startup. You won't need the XG startup as that's for the XA
> Gateway which is only of interest if you want your RMS updates controlled
by
> some sort of XA monitor like Tuxedo. (The XA Veneer on the other hand
(that
> doesn't need a seperate process) is useful if you want to update Orrible
> Oracle on VMS in the same 2PC as your Rdb, RMS (and possibly Windows SQL
> Server) databases.
>
> I still don't know why people persist in saying that VAX COBOL does not
> support commit/rollback verbs when the pointer to the docs that I posted
> previous seems to show that it does? No matter; now that I know what
you're
> doing I'm intrigued!
>
> I love VMS (always will) I love seeing stuff ported to VMS; the more the
> better! Having said that, who the hell is giving you funding for this
crap?
> Keep it on IBM and just change the incontinence nappies every now and then
> (works for VMS engineering :-)
>
> OK we are where we are: - What database exactly was the COBOL talking to
on
> IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not knowing
> anything at all about IBM) that all the CICS stuff used precompilers and
had
> EXEC-SQL in the code everywhere.
>
> What about all the JCL? How do you intend to backup your data? You may
have
> RUJ functionality but what about AIJ functionality and roll forward to
point
> in time? Does it get distributed anywhere? Data wharehouses?
>
> Look I'm sure you thought all this through and I wish you well, but if you
> want cheap, leave it on IBM. If you want to do it right then re-write it
on
> VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving ,
> oligarchic gravy-train that is currently running it into the buffers.
>
> Cheers Richard Maher
>
> PS. Here's a web site where you can often hear from Jim Johnson if you
miss
> him, and can also reminisce about what it was like to be in a living
> development environment: -
>
> http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1
>
> Digital had it way back when :-(
>
> PPS> There used to be an RPG II compiler on PDPs don't know if it ever
made
> it to VMS.
>
> "Paul Raulerson" wrote in message
> news:000301c7e532$25d7be90$71873bb0$@com...
> >
> > [SNIP SNIP SNIP]
> > > -----Original Message-----
> > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> > > Sent: Wednesday, August 22, 2007 6:11 PM
> > > To: Info-VAX@Mvb.Saic.Com
> > > Subject: Re: COBOL Transactions?
> > >
> > [SNIP]
> >
> > Hey Richard, do you have a pointer to how to turn this DDTM *on*?
> > I have found:
> > DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
> > DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
> > DECDTM$STARTUP.COM;1
> >
> > and ran the DECDTM$STARTUP.com script, which seems to have succeeded.
Also
> > ran the DDTM$XG_START_SERVER.com
> > script, and they *seem* to be running.
> >
> > Marked a test file with SET FILE/RU_JOURNAL and it seems to report
itself
> > correctly.
> >
> > Constantly get back a failure code, 933B.
> >
> > Ran the example script, created the files and still get the same error
> code.
> > I do not know if it is a license thing or not. Show license finds the
> > following lines, so I think it is licensed.
> >
> > DTM DEC 0 0 100 0.0 (none)
> > 31-JUL-2008
> > RMSJNL DEC 0 0 100 0.0 (none)
> > 31-JUL-2008
> >
> > I cannot find any startup files or stuff with *RMS* in the name to run
or
> > whatever.
> >
> > I did scan through the manuals I could find, and the RMS Journal manual
> was
> > clear that DECdtm has to be
> > running first, but ... not really working. Advice? Pointers?
> Thanks -Paul
> >
> >
>
>

On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
wrote:

> On 08/23/07 08:25, Tom Linden wrote:
>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>> wrote:
>>
>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>> handling
>>> capabilities, something that is NOT true of other languages. Part of
>>> the
>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>>> it is
>>> not required in the language spec for COBOL 85. I believe it is for
>>> the new
>>> spec coming out...
>>
>> Indexed file handling is in the PL/I semantics.
>
> Yeah, but anyone in his right mind knows that PL/1 sucks.
>
That would be PL/I BTW, you obviously know little about programming
languages.


--
PL/I for OpenVMS
www.kednos.com

> -----Original Message-----
> From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> Sent: Thursday, August 23, 2007 6:04 AM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: COBOL Transactions?
>
> Hi Paul,
>
Thanks, between you and Alex that absolutely targeted the problem. Works
great right now.

> I still don't know why people persist in saying that VAX COBOL does not
> support commit/rollback verbs when the pointer to the docs that I
> posted
> previous seems to show that it does? No matter; now that I know what
> you're
> doing I'm intrigued!
>
> I love VMS (always will) I love seeing stuff ported to VMS; the more
> the
> better! Having said that, who the hell is giving you funding for this
> crap?
> Keep it on IBM and just change the incontinence nappies every now and
> then
> (works for VMS engineering :-)
>

Funding is from me, myself, and my wife. One reason why I need to
make sure it will work on the cheap.
We do have some alternatives, but none of them are quite as cool as the
small Itanium packages available from HP, and well - VMS is pretty nice.
Different, but nice.



> OK we are where we are: - What database exactly was the COBOL talking
> to on
> IBM? DB2? Or a Codasyl compliant database? VISAM? I thought (not
> knowing
> anything at all about IBM) that all the CICS stuff used precompilers
> and had
> EXEC-SQL in the code everywhere.
>

Depends on the customer of course, it can be DB/2, Oracle, AdaBASE, or a few
others. I tend to prefer CICS and VSAM files for most things, and DB/2 for
everything else. DB/2 is built for performance on the mainframe, and it
shows. CICS does use a precompiler, but if you use the database, you are
just using the database; little or no
recourse to CICS.

VSAM access, on the other hand, is serialized in CICS and can cross regions
easily. EXEC CICS READ etc. CICS (or Transaction Server, to use it's now 10
year old "new" name... is really how you run interactive programs on
z/OS, since z/OS itself is not the worlds most interactive environment.
Foreground compiles are frowned upon, to say the least. VMS is so
interaction it seems almost chaotic at times, or perhaps just libertarian?


> What about all the JCL? How do you intend to backup your data? You may
> have
> RUJ functionality but what about AIJ functionality and roll forward to
> point
> in time? Does it get distributed anywhere? Data wharehouses?
>

The (so far very small) Data Warehouse and business intelligence processing
takes advantage of DB/2 almost entirely. It is not a terribly important part
to port immediately, and is scheduled for porting after I have gotten much
further through than I have right now.

JCL isn't so much of a big deal in an interactive environment; it looks like
an awful lot of that can be setup for interactive sessions via DCL, and what
little cannot, can be handled with standalone DCL programs (.COM files?)

Backup and so forth are issues I have to address. In the very lowest end
market, it ain't much of a problem. Stick a DVD in there once a week or so,
and a tape per day. At the high end, the local system programmers will take
care of it. But in the middle regions, from the modest little small business
up to the midsize companies, it can become an issue. I am thinking of taking
an appliance approach, or selling remote services for backup, or something.

I don't have a good plan there. Open to ideas!


> Look I'm sure you thought all this through and I wish you well, but if
> you
> want cheap, leave it on IBM. If you want to do it right then re-write
> it on
> VMS. Me? I'd go Rdb *every* time, despite the poisonous, self-serving
> ,
> oligarchic gravy-train that is currently running it into the buffers.
>

It ain't cheap on the IBM. Just to run zSeries today, you have to spend
close to $700K, and that's usually before software costs. Would you believe
that 5 years ago, you could entry level for a mere $60K? Or even less.
(*sigh*)
If you move everything to iSeries (AS/400) or pSeries (RS/6000) yeah, it
gets cheaper. $14K - $18K entry on the iSeries, and 4K to 9K entry on the
RS/6000. But - iSeries programs are very different, and mainframe style
programs do *not* port all that well. (Well, the screens do...) On the
RS/6000, you spend more time building the tools to build the tools to build
the tools than you do getting anything done, unless of course, you are
willing to mortgage your future to MicroFocus or some other $400/user
solution. Yuck.

VMS has the unique distinction of being available on Tiny machines all the
way up to near mainframe class machines. And is a rich operating systems
with a very high class, if wordy when you make an error, COBOL compiler.

I'm excited about it, and know I need to move this to Itanium, but being
cheap, I think I will do a porting event thing as soon as I have enough
ported, working, and tested on the little Alpha here. The only issue with
the Alpha is that the 4mm tape drive on it does not seem to be recognized.
No big matter - source gets backed up to disk
3 times per day, and FTP'ed off to the UNIX machine which *does* know how to
talk to tape. Tapes go into the library, the safe, and my lower left hand
desk drawer at my "day" job!

Thanks again for the advice and help!

_Paul

> Cheers Richard Maher
>
> PS. Here's a web site where you can often hear from Jim Johnson if you
> miss
> him, and can also reminisce about what it was like to be in a living
> development environment: -
>
> http://forums.microsoft.com/MSDN/Sho...D=388&SiteID=1
>
> Digital had it way back when :-(
>
> PPS> There used to be an RPG II compiler on PDPs don't know if it ever
> made
> it to VMS.
>
> "Paul Raulerson" wrote in message
> news:000301c7e532$25d7be90$71873bb0$@com...
> >
> > [SNIP SNIP SNIP]
> > > -----Original Message-----
> > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> > > Sent: Wednesday, August 22, 2007 6:11 PM
> > > To: Info-VAX@Mvb.Saic.Com
> > > Subject: Re: COBOL Transactions?
> > >
> > [SNIP]
> >
> > Hey Richard, do you have a pointer to how to turn this DDTM *on*?
> > I have found:
> > DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
> > DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
> > DECDTM$STARTUP.COM;1
> >
> > and ran the DECDTM$STARTUP.com script, which seems to have succeeded.
> Also
> > ran the DDTM$XG_START_SERVER.com
> > script, and they *seem* to be running.
> >
> > Marked a test file with SET FILE/RU_JOURNAL and it seems to report
> itself
> > correctly.
> >
> > Constantly get back a failure code, 933B.
> >
> > Ran the example script, created the files and still get the same
> error
> code.
> > I do not know if it is a license thing or not. Show license finds the
> > following lines, so I think it is licensed.
> >
> > DTM DEC 0 0 100 0.0 (none)
> > 31-JUL-2008
> > RMSJNL DEC 0 0 100 0.0 (none)
> > 31-JUL-2008
> >
> > I cannot find any startup files or stuff with *RMS* in the name to
> run or
> > whatever.
> >
> > I did scan through the manuals I could find, and the RMS Journal
> manual
> was
> > clear that DECdtm has to be
> > running first, but ... not really working. Advice? Pointers?
> Thanks -Paul
> >
> >
>

Wow - I freely admit to ignorance on this - I've always (in the IBM world)
seen it written as PL/1, with an arabic "1" instead of a Roman Numeral "I".
They *are* the same language are they not, or are they different?

-Paul


> -----Original Message-----
> From: Tom Linden [mailto:tom@kednos.company]
> Sent: Thursday, August 23, 2007 8:03 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: COBOL Transactions?
>
> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
> wrote:
>
> > On 08/23/07 08:25, Tom Linden wrote:
> >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>
> >> wrote:
> >>
> >>> Not so. COBOL is not COBOL unless it supplies certain indexed file
> >>> handling
> >>> capabilities, something that is NOT true of other languages. Part
> of
> >>> the
> >>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords,
> though
> >>> it is
> >>> not required in the language spec for COBOL 85. I believe it is for
> >>> the new
> >>> spec coming out...
> >>
> >> Indexed file handling is in the PL/I semantics.
> >
> > Yeah, but anyone in his right mind knows that PL/1 sucks.
> >
> That would be PL/I BTW, you obviously know little about programming
> languages.
>
>
> --
> PL/I for OpenVMS
> www.kednos.com

On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
wrote:

> Wow - I freely admit to ignorance on this - I've always (in the IBM
> world)
> seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
> "I".
> They *are* the same language are they not, or are they different?
>
Yes. Even on IBM gear it is the Roman numeral.


> -Paul
>
>
>> -----Original Message-----
>> From: Tom Linden [mailto:tom@kednos.company]
>> Sent: Thursday, August 23, 2007 8:03 PM
>> To: Info-VAX@Mvb.Saic.Com
>> Subject: Re: COBOL Transactions?
>>
>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
>> wrote:
>>
>> > On 08/23/07 08:25, Tom Linden wrote:
>> >> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>>
>> >> wrote:
>> >>
>> >>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>> >>> handling
>> >>> capabilities, something that is NOT true of other languages. Part
>> of
>> >>> the
>> >>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords,
>> though
>> >>> it is
>> >>> not required in the language spec for COBOL 85. I believe it is for
>> >>> the new
>> >>> spec coming out...
>> >>
>> >> Indexed file handling is in the PL/I semantics.
>> >
>> > Yeah, but anyone in his right mind knows that PL/1 sucks.
>> >
>> That would be PL/I BTW, you obviously know little about programming
>> languages.
>>
>>
>> --
>> PL/I for OpenVMS
>> www.kednos.com
>



--
PL/I for OpenVMS
www.kednos.com

On Aug 23, 9:19 pm, "Paul Raulerson" wrote:
> The only issue with
> the Alpha is that the 4mm tape drive on it does not seem to be recognized.

Given your inexperience with OpenVMS, perhaps you just don't know
where to look for the device name?

Have you tried $SHOW DEVICE MK

Maybe the tape drive is dead? Hardware failures have been known to
occur.

> off to the UNIX machine which *does* know how to
> talk to tape.

This is what makes you so annoying. You have admitted to having
little experience with OpenVMS and yet you make statements like
"OpenVMS can't do X like all those other operating systems". IIRC at
every turn you've been shown to be incorrect about OpenVMS'
capabilities.

Of course OpenVMS can work with tapes. Even file-oriented if that's
your desire. Get the hardware working, learn to recognize the device
name, and then it'll be trivial to do a backup to tape.

Rather than making statements about what OpenVMS can or can't do,
you'd be a lot better served (and earn more respect) by learning to
ask questions first. Like, "how do I find my tape drive", "is there
an RPG compiler for OpenVMS", "is it RDB or RMS that handles indexed
file support", "how do I convert a status value to text in Cobol",
etcetera.

Ron Johnson wrote:
> On 08/23/07 08:25, Tom Linden wrote:
>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>> wrote:
>>
>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>> handling
>>> capabilities, something that is NOT true of other languages. Part of the
>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>>> it is
>>> not required in the language spec for COBOL 85. I believe it is for
>>> the new
>>> spec coming out...
>> Indexed file handling is in the PL/I semantics.
>
> Yeah, but anyone in his right mind knows that PL/1 sucks.
>

It had (has?) all the best features of cobol and fortran (and C)
combined into a single package.

In article ,
"Tom Linden" writes:
> On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
> wrote:
>
>> Wow - I freely admit to ignorance on this - I've always (in the IBM
>> world)
>> seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
>> "I".
>> They *are* the same language are they not, or are they different?
>>
> Yes. Even on IBM gear it is the Roman numeral.

I don't want to start a flame war over something as trivial as this, but
it was definitely a "1" on the Primes I worked on and I have numerous
books in my library (sadly, packed up at this point so I can't get any
actual titles) that use the logo "PL/1".

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

On 08/23/07 20:02, Tom Linden wrote:
> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
> wrote:
>
>> On 08/23/07 08:25, Tom Linden wrote:
>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>>> wrote:
>>>
>>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>>> handling
>>>> capabilities, something that is NOT true of other languages. Part of
>>>> the
>>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>>>> it is
>>>> not required in the language spec for COBOL 85. I believe it is for
>>>> the new
>>>> spec coming out...
>>>
>>> Indexed file handling is in the PL/I semantics.
>>
>> Yeah, but anyone in his right mind knows that PL/1 sucks.
>>
> That would be PL/I BTW, you obviously know little about programming
> languages.

So you also say that PL/I sucks?

(Just jerking your chain, Tom, since you are such a big booster of a
not-so-popular-anymore language. Was it ever very popular outside
the mainframe?)

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

In article ,
Ron Johnson writes:
> On 08/23/07 20:02, Tom Linden wrote:
>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
>> wrote:
>>
>>> On 08/23/07 08:25, Tom Linden wrote:
>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>>>> wrote:
>>>>
>>>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>>>> handling
>>>>> capabilities, something that is NOT true of other languages. Part of
>>>>> the
>>>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>>>>> it is
>>>>> not required in the language spec for COBOL 85. I believe it is for
>>>>> the new
>>>>> spec coming out...
>>>>
>>>> Indexed file handling is in the PL/I semantics.
>>>
>>> Yeah, but anyone in his right mind knows that PL/1 sucks.
>>>
>> That would be PL/I BTW, you obviously know little about programming
>> languages.
>
> So you also say that PL/I sucks?
>
> (Just jerking your chain, Tom, since you are such a big booster of a
> not-so-popular-anymore language. Was it ever very popular outside
> the mainframe?)

Minicomputers. Prime used it and much of the OS and utilites was written
in PL/1 :-) and various subset dialects.

Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies
as a dialect.)

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

On Fri, 24 Aug 2007 05:27:05 -0700, Bill Gunshannon
wrote:

> In article ,
> "Tom Linden" writes:
>> On Thu, 23 Aug 2007 18:31:56 -0700, Paul Raulerson
>> wrote:
>>
>>> Wow - I freely admit to ignorance on this - I've always (in the IBM
>>> world)
>>> seen it written as PL/1, with an arabic "1" instead of a Roman Numeral
>>> "I".
>>> They *are* the same language are they not, or are they different?
>>>
>> Yes. Even on IBM gear it is the Roman numeral.
>
> I don't want to start a flame war over something as trivial as this, but
> it was definitely a "1" on the Primes I worked on and I have numerous
> books in my library (sadly, packed up at this point so I can't get any
> actual titles) that use the logo "PL/1".
Well that was my compiler, and the command was
pli
>
> bill
>



--
PL/I for OpenVMS
www.kednos.com

On Fri, 24 Aug 2007 05:31:18 -0700, Ron Johnson
wrote:

> On 08/23/07 20:02, Tom Linden wrote:
>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
>> wrote:
>>
>>> On 08/23/07 08:25, Tom Linden wrote:
>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>>>>
>>>> wrote:
>>>>
>>>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>>>> handling
>>>>> capabilities, something that is NOT true of other languages. Part of
>>>>> the
>>>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords,
>>>>> though
>>>>> it is
>>>>> not required in the language spec for COBOL 85. I believe it is for
>>>>> the new
>>>>> spec coming out...
>>>>
>>>> Indexed file handling is in the PL/I semantics.
>>>
>>> Yeah, but anyone in his right mind knows that PL/1 sucks.
>>>
>> That would be PL/I BTW, you obviously know little about programming
>> languages.
>
> So you also say that PL/I sucks?
>
> (Just jerking your chain, Tom, since you are such a big booster of a
> not-so-popular-anymore language. Was it ever very popular outside
> the mainframe?)
And I yours:-) It sold pretty well on the VAX, and was/is used by many of
the
three letter agencies both here and abroad. Did/does very well in
Aerospace (used
both at NASA and ESA) and Automotive, Steel, Insurance, Banking
>
Here is a good piece of propoganda
http://www.kednos.com/pli/king.pdf


--
PL/I for OpenVMS
www.kednos.com

On 08/24/07 08:18, Bill Gunshannon wrote:
> In article ,
> Ron Johnson writes:
>> On 08/23/07 20:02, Tom Linden wrote:
>>> On Thu, 23 Aug 2007 07:25:52 -0700, Ron Johnson
>>> wrote:
>>>
>>>> On 08/23/07 08:25, Tom Linden wrote:
>>>>> On Wed, 22 Aug 2007 21:37:53 -0700, Paul Raulerson
>>>>> wrote:
>>>>>
>>>>>> Not so. COBOL is not COBOL unless it supplies certain indexed file
>>>>>> handling
>>>>>> capabilities, something that is NOT true of other languages. Part of
>>>>>> the
>>>>>> normal COBOL thing is to supply the BEGIN TRANSACTION keywords, though
>>>>>> it is
>>>>>> not required in the language spec for COBOL 85. I believe it is for
>>>>>> the new
>>>>>> spec coming out...
>>>>> Indexed file handling is in the PL/I semantics.
>>>> Yeah, but anyone in his right mind knows that PL/1 sucks.
>>>>
>>> That would be PL/I BTW, you obviously know little about programming
>>> languages.
>> So you also say that PL/I sucks?
>>
>> (Just jerking your chain, Tom, since you are such a big booster of a
>> not-so-popular-anymore language. Was it ever very popular outside
>> the mainframe?)
>
> Minicomputers. Prime used it and much of the OS and utilites was written
> in PL/1 :-) and various subset dialects.

Prime has been dead for how many years now? 15?

> Microcomputers. PL/M (well, it may not be PL/1, but I think it qualifies
> as a dialect.)

Who used PL/M besides DRI?

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!