× 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.



One more thing, in case it may help. I've done work at one or two places where most of their native externally DDS-created files were kept in QS36 libraries. At first glance I groaned a bit but then saw that they were DDS-defined.

Alan


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of M. Lazarus
Sent: Tuesday, November 05, 2013 1:04 PM
To: Midrange Systems Technical Discussion
Subject: Re: Questions about S/36 files

James,

If you are using the S/36 commands (BLDFILE and BLDINDEX), you will be somewhat limited. For example, the key on the PF must be contiguous. The key on an alternate index (aka LF) is limited to 3 keys. The field(s) will be generated by the system: F00001. If there is a key, that field will be named K00001. If there is more data after the key it will get named F00002, etc. (I think I have the correct number of zeros.)

There is no need for that, though. You can externally define the file and access internally, just as you would for a flat file.

You can certainly emulate the 36EE's logic when creating a file in DDS that would look like a 36EE file. But convenient? Not really.

By externally describing it, you can use SQL for native operations and internally define it in an RPG program.

-mark

At 11/5/2013 12:08 PM, you wrote:
A couple of questions about S/36 files, prompted by a potential new
customer whose whole native system is apparently set up around them:

First, while I've occasionally futzed around with totally flat,
non-keyed files, and while I've used program-described mode to
circumvent level-check problems on externally-described files that
change regularly, but in a manner that's under our control, I don't
have a lot of experience with actual S-36 files. Am I correct in my
understanding that an S-36 file can be both flat and keyed at the same
time? Is there a convenient way to create a file indistinguishable from
an S-36 file on a V4 or V6 box that doesn't have any S-36 emulation
installed?

Second, can SQL access an S-36 file? Is it difficult?

--
JHHL

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.