× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: S/36 MRT programs (some questions)
  • From: "Marc Zylka" <mzylka@xxxxxxxxxxx>
  • Date: Fri, 16 Jan 1998 20:23:27 -0500

Thanks, for those who responded, for the responses.

Pete,

  This must have been one pain in the butt to test and code.  The programs
I'm looking at seem to have been
designed to take advantage of the memory savings only.  I did see one case
where a contract number was
being processed for all 5 (KNUM=5) sessions but I'm not sure why.  I'll have
to look at that closer.  It's
obvious there's more to look at than I thought.  Hmm, maybe I'll give it to
our contractor.   ; - )

Thanks, Marc

>Since all MRT requesters share the same file cursors, you may have trouble
with records being left locked. Make sure that record locks are always
released. Control records that contains a values that are updated frequently
can cause problems. Also beware of deadlock situations.
>
>Sometimes variables are omitted from the save data structure or shared
indicator array. This could be because their initial state is insignificant,
but it could also be because the variable is used to communicate between all
attached sessions. Next invoice number, next record number, etc. You need to
figure out the usage of each field that is not defined in the save data
structure and each indicator that is not saved. You may need to use a shared
user space or data area to provide interprocess communication, and if you
do, you'll need to either explicitly move values to/from it, where this had
been handled implicitly before, or pass pointers to the external shared data
space and synchronize the access to it, thereby emulating the behavior of
the MRT in your code.
>
>hth
>Pete
>
>
>Pete Hall
>peteh@inwave.com
>http://www.inwave.com/~peteh/
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
>| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator:
david@midrange.com
>+---
>uucp

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.