Re: Questions about S/36 files -- MIDRANGE-L

Sadly I'm still supporting a s36 based app that was written by IBM almost 20 years ago.

Rob is correct SQL will work but you would have to know what data is in the big field F000002 and sub string it. You can create dds for that file and just copy the data in - or internally define the file in your rpg program. You would of course need to know the file layout - possibly from the F&i specs in the existing programs if you have them.

I still have the S36 env on my V5R4 box if you want anything looked at

Cheers

Kevin

Kevin Passey
00447710023215

On 5 Nov 2013, at 22:21, midrange-l-request@xxxxxxxxxxxx wrote:

Send MIDRANGE-L mailing list submissions to
midrange-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
midrange-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MIDRANGE-L digest..."

*** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.

Today's Topics:

1. Re: Questions about S/36 files (rob@xxxxxxxxx)
2. RE: Questions about S/36 files (Scott Schollenberger)
3. Re: Questions about S/36 files (Horn, Jim)
4. Re: Questions about S/36 files (Pat Barber)
5. Re: SAVE 21 - console required? Or just controlling
subsystem? (Evan Harris)
6. Cleanup Tasks - 1 hour off due to time change (Steinmetz, Paul)

----------------------------------------------------------------------

message: 1
date: Tue, 5 Nov 2013 16:28:17 -0500
from: rob@xxxxxxxxx
subject: Re: Questions about S/36 files

Wrong. SQL does work

INSERT INTO QS36F/JIMMY (F00001, K00001, F00002) VALUES('A', 'B',
'C')
1 rows inserted in JIMMY in QS36F.

select * from qs36f/jimmy
....+....1....+....2....+....3....+....4....+....5....
F00001 K00001 F00002
A B C
******** End of data ********

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Pat Barber <mboceanside@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/05/2013 04:10 PM
Subject: Re: Questions about S/36 files
Sent by: midrange-l-bounces@xxxxxxxxxxxx

There are NO S/36 files on the I, but a very simple DDS that represents
the S/36 file.

The following is a 256 byte file with a index key of 11 in the first 11
bytes.

It is externally described but a very VERY short description with one
field and one key
description. The system doesn't care if it is "flat" or "DDS" described,
they
would work no matter what.

SQL would not work because the file is NOT externally described

Note the names created by the system.

The following file was created using BLDFILE command.

The file description states that this file is "NOT"
externally described because of the file creation method.

Display File Field Description
Input parameters
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : *LIBL
File Information
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : TCS
File location . . . . . . . . . . . . . . . : *LCL
Externally described . . . . . . . . . . . : No
Number of record formats . . . . . . . . . : 1
Type of file . . . . . . . . . . . . . . . : Physical
File creation date . . . . . . . . . . . . : 09/30/13
Record Format Information
Record format . . . . . . . . . . . . . . . : ACCTS
Format level identifier . . . . . . . . . . : 2696BD8B9F35D
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 256
Field Level Information
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
K00001 CHAR 11 11 1 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535
F00001 CHAR 245 245 12 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535

A simple conversion to native should not take over a few minutes "IF"
you know the correct file layout. It will take longer to key the DDS
than anything else.

Yes you can create a S/36 "like" file by using a
CRTPF FILE(TCS/SAMPLE1) RCDLEN(256) but it is still a
DDS described file as far as the system is concerned.

On 11/5/2013 9:08 AM, James H. H. Lampert 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.

------------------------------

message: 2
date: Tue, 5 Nov 2013 21:30:32 +0000
from: Scott Schollenberger <SSchollenberger@xxxxxxxxxxxxxxxxxx>
subject: RE: Questions about S/36 files

You could also pull out data using the SUBSTR function on the fields in a SELECT statement. It isn't pretty but it works.

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

Wrong. SQL does work

INSERT INTO QS36F/JIMMY (F00001, K00001, F00002) VALUES('A', 'B',
'C')
1 rows inserted in JIMMY in QS36F.

select * from qs36f/jimmy
....+....1....+....2....+....3....+....4....+....5....
F00001 K00001 F00002
A B C
******** End of data ********

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Pat Barber <mboceanside@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 11/05/2013 04:10 PM
Subject: Re: Questions about S/36 files
Sent by: midrange-l-bounces@xxxxxxxxxxxx

There are NO S/36 files on the I, but a very simple DDS that represents
the S/36 file.

The following is a 256 byte file with a index key of 11 in the first 11
bytes.

It is externally described but a very VERY short description with one
field and one key
description. The system doesn't care if it is "flat" or "DDS" described,
they
would work no matter what.

SQL would not work because the file is NOT externally described

Note the names created by the system.

The following file was created using BLDFILE command.

The file description states that this file is "NOT"
externally described because of the file creation method.

Display File Field Description
Input parameters
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : *LIBL
File Information
File . . . . . . . . . . . . . . . . . . . : ACCOUNTS
Library . . . . . . . . . . . . . . . . . : TCS
File location . . . . . . . . . . . . . . . : *LCL
Externally described . . . . . . . . . . . : No
Number of record formats . . . . . . . . . : 1
Type of file . . . . . . . . . . . . . . . : Physical
File creation date . . . . . . . . . . . . : 09/30/13
Record Format Information
Record format . . . . . . . . . . . . . . . : ACCTS
Format level identifier . . . . . . . . . . : 2696BD8B9F35D
Number of fields . . . . . . . . . . . . . : 2
Record length . . . . . . . . . . . . . . . : 256
Field Level Information
Data Field Buffer Buffer Field Column
Field Type Length Length Position Usage Heading
K00001 CHAR 11 11 1 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535
F00001 CHAR 245 245 12 Both
Keyboard shift . . . . . . . . . . . . . : A
Coded Character Set Identifier . . . . . : 65535

A simple conversion to native should not take over a few minutes "IF"
you know the correct file layout. It will take longer to key the DDS
than anything else.

Yes you can create a S/36 "like" file by using a
CRTPF FILE(TCS/SAMPLE1) RCDLEN(256) but it is still a
DDS described file as far as the system is concerned.

On 11/5/2013 9:08 AM, James H. H. Lampert 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.

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

________________________________

Scott Schollenberger
Vice President, Research & Development

P: 610-239-9988 x305
F: 610-239-9995
E: SSchollenberger@xxxxxxxxxxxxxxxxxx
[http://www.harriscomputer.com/images/signatures/HarrisSchools.jpg]

[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]<http://www.harriscomputer.com/>
100-2011 Renaissance Blvd.
King of Prussia, PA
19406
www.harris-schoolsolutions.com<http://www.harris-schoolsolutions.com>

This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message.

------------------------------

message: 3
date: Tue, 5 Nov 2013 15:41:07 -0600
from: "Horn, Jim" <jim.horn@xxxxxxxxxxxxxx>
subject: Re: Questions about S/36 files

Oh for the simpler times! OCL sorts that created addrouts. The wonder of
it's day. :)

The rpg seemed comparatively easy compared to the OCL to CL.

------------------------------

message: 3
date: Tue, 05 Nov 2013 14:00:51 -0600
from: Booth Martin <booth@xxxxxxxxxxxx>
subject: Re: Questions about S/36 files

The file issue is the minor issue. Its fairly straight forward and in a
few hours you will have it sorted out in your mind.

That is not where you will get your frustrations. The frustrations will
come from the hardware restraints that programmers had to works with 30
years ago. Their work-arounds and shortcuts worked, but you will regret
having to deal with them. The MOVE opcode can do things those
programmers needed done, but it will make you gasp, defining a numeric
field with varying lengths so it will fit on a printed page will mystify
you, defining a field as alpha or numeric, depending how you wish to use
it in your program will make you cringe. Seeing whole programs written,
and temporary files created, sorted, used, and destroyed just to do some
small piece of a report will trouble you. And, we haven't even begun to
discuss the hoops created by CL program manipulation of files.

In short, I have done dozens of these and they always start out looking
like _this_ one will be different. They never are, Programmers back
then did the best they could with what was available, but since then a
whole lot more has become available. I will offer this hint: if you are
going to do it, start with the smallest, least significant application
first. Get your feet wet, and get a success early on, so you will have
a better basis to decide whether or not to continue. My estimate is
that, once you understand what is happening in an application, you can
probably write the same thing, new, in 20% of the time it will take to
update the existing application.

But yes, the files can be keyed. The keys are contiguous and added to
the end of the record, even if they are identical to data fields in the
original record, There is also another feature called the ADDROUT file
which is a separate file made up of only addresses. A data file can
have any number of these detached address files, allowing an early
version of indexed files.

--

***********************************************************************
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender and
delete the material from any computer. As a recipient of this email,
you are responsible for screening its contents and the contents of any
attachments for the presence of viruses. No liability is accepted for
any damages caused by any virus transmitted by this email.

------------------------------

message: 4
date: Tue, 05 Nov 2013 13:51:16 -0800
from: Pat Barber <mboceanside@xxxxxxx>
subject: Re: Questions about S/36 files

I had no idea that would work..

Is Jimmy externally defined ?

On 11/5/2013 1:28 PM, rob@xxxxxxxxx wrote:
Wrong. SQL does work

INSERT INTO QS36F/JIMMY (F00001, K00001, F00002) VALUES('A', 'B',
'C')
1 rows inserted in JIMMY in QS36F.

select * from qs36f/jimmy
....+....1....+....2....+....3....+....4....+....5....
F00001 K00001 F00002
A B C
******** End of data ********

Rob Berendt

------------------------------

message: 5
date: Wed, 6 Nov 2013 11:06:52 +1300
from: Evan Harris <auctionitis@xxxxxxxxx>
subject: Re: SAVE 21 - console required? Or just controlling
subsystem?

HI

I remember doing just this back in the old green screen days. Meant I could
use any old terminal to run the save.

However, those terminals didn't need TCP unlike most current access
mechanisms. A Console device is likely to connect over the short TCP stack
and continue operatingduring your save whereas a device just transferred
into QCTL is likely to fail as soon as TCP is ended.

I suspect the message is a hangover from the old days of green screen
terminal devices.

But I'll be interested to see how this pans out.

On Wed, Nov 6, 2013 at 9:17 AM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>wrote:

I've only ever done SAVE 21 from the console. I always ass-u-med the
console was required.

But if you take the SAVE 21 option from a display not in the controlling
subsystem, it only says you must first transfer the job into the
controlling subsystem, then take the SAVE 21 option again. It does _not_
say you need to be at the console.

I infer from that, that it does _not_ need to be run from the console. Am
I right?

--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.

--

Regards
Evan Harris

------------------------------

message: 6
date: Tue, 5 Nov 2013 17:21:21 -0500
from: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
subject: Cleanup Tasks - 1 hour off due to time change

If you use the auto cleanup tasks, it will be an hour off due to the time change.
4. End cleanup usually does not work.
You need to endjob QSYSSCD.
QCTL QSYS SBS .0 DEQW
QSYSSCD QPGMR BCH .0 PGM-QEZSCNEP EVTW
Then 2. Start cleanup at scheduled time

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/

------------------------------

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest 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.

End of MIDRANGE-L Digest, Vol 12, Issue 2139
********************************************