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



NO.

- Larry "DrFranken" Bolhuis

www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.

On 8/16/2017 9:23 AM, Paul Crow wrote:
Hi All,

Is there a way to create a Virtual Tape on a QNTC share, I have tried in the past but been plagued by Authority issues, even though the user had full access to the share itself, able to copy files etc using the cpy cmd, It seems the issue is when using the command to create the virtual tape it uses Qsecofr to create the object and not the logged on user!


Paul Crow

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of midrange-l-request@xxxxxxxxxxxx
Sent: 16 August 2017 10:36
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 16, Issue 1295

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: access API from CLLE (Justin Taylor)
2. RE: access API from CLLE (Paul Therrien)
3. Secured txt file (Gad Miron)
4. Re: Secured txt file (Jack Woehr)
5. Re: Secured txt file (Tim Bronski)
6. Re: Secured txt file (Jonathan Wilson)


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

message: 1
date: Tue, 15 Aug 2017 17:07:27 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: access API from CLLE

Perfect, thank you!

I never would have thought to put the procedure name in quotes.




-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2017 5:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: access API from CLLE

Hi Justin,

On 8/14/2017 4:57 PM, Justin Taylor wrote:
Can anyone share a sample of the access() IFS API from CLLE?


Sure, here's an example that I already had laying around... not sure what I originally wrote this for, but I think it illustrates things well enough.

PGM

DCL VAR(&RtnVar) TYPE(*INT) LEN(4)
DCL VAR(&Null) TYPE(*CHAR) LEN(1) VALUE(X'00')
DCL VAR(&SomeFile) TYPE(*CHAR) LEN(64)
DCL VAR(&Mode) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&ErrPtr) TYPE(*PTR)
DCL VAR(&Errno) TYPE(*INT) LEN(4) +
STG(*BASED) BASPTR(&ErrPtr)
DCL VAR(&MsgNo) TYPE(*DEC) LEN(4 0)
DCL VAR(&MsgNoC) TYPE(*CHAR) LEN(4)
DCL VAR(&MsgId) TYPE(*CHAR) LEN(7)

DCL VAR(&F_OK) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&R_OK) TYPE(*INT) LEN(4) VALUE(4)
DCL VAR(&W_OK) TYPE(*INT) LEN(4) VALUE(2)
/* DCL VAR(&X_OK) TYPE(*INT) LEN(4) VALUE(1) */

CHGVAR VAR(&SomeFile) VALUE('/qibm/ProdData/Access/Windows+
/Install/Image/SETUP.EXE' *TCAT &NULL)

/*===================================== */
/* Check for file existence */
/*===================================== */

CALLPRC PRC('access') PARM((&SomeFile) +
(&F_OK *ByVal)) +
RTNVAL(&RtnVar)

if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('Exists' *bcat &SomeFile)
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo

/*===================================== */
/* Check for read/write access */
/*===================================== */

CHGVAR VAR(&Mode) VALUE(&R_OK + &W_OK)
CALLPRC PRC('access') PARM((&SomeFile) +
(&Mode *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('You have read & write access!')
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo

ENDPGM


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

message: 2
date: Tue, 15 Aug 2017 17:12:29 -0400
from: "Paul Therrien" <paultherrien@xxxxxxxxxxxxxxxxxx>
subject: RE: access API from CLLE

Kudos and appreciation to David Gibbs and all the contributors on this site.
The below exchange came just at the right time for a program I am writing.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Justin Taylor
Sent: Tuesday, August 15, 2017 1:07 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: access API from CLLE

Perfect, thank you!

I never would have thought to put the procedure name in quotes.




-----Original Message-----
From: Scott Klement [mailto:midrange-l@xxxxxxxxxxxxxxxx]
Sent: Monday, August 14, 2017 5:47 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: access API from CLLE

Hi Justin,

On 8/14/2017 4:57 PM, Justin Taylor wrote:
Can anyone share a sample of the access() IFS API from CLLE?


Sure, here's an example that I already had laying around... not sure what I originally wrote this for, but I think it illustrates things well enough.

PGM

DCL VAR(&RtnVar) TYPE(*INT) LEN(4)
DCL VAR(&Null) TYPE(*CHAR) LEN(1) VALUE(X'00')
DCL VAR(&SomeFile) TYPE(*CHAR) LEN(64)
DCL VAR(&Mode) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&ErrPtr) TYPE(*PTR)
DCL VAR(&Errno) TYPE(*INT) LEN(4) +
STG(*BASED) BASPTR(&ErrPtr)
DCL VAR(&MsgNo) TYPE(*DEC) LEN(4 0)
DCL VAR(&MsgNoC) TYPE(*CHAR) LEN(4)
DCL VAR(&MsgId) TYPE(*CHAR) LEN(7)

DCL VAR(&F_OK) TYPE(*INT) LEN(4) VALUE(0)
DCL VAR(&R_OK) TYPE(*INT) LEN(4) VALUE(4)
DCL VAR(&W_OK) TYPE(*INT) LEN(4) VALUE(2)
/* DCL VAR(&X_OK) TYPE(*INT) LEN(4) VALUE(1) */

CHGVAR VAR(&SomeFile) VALUE('/qibm/ProdData/Access/Windows+
/Install/Image/SETUP.EXE' *TCAT &NULL)

/*===================================== */
/* Check for file existence */
/*===================================== */

CALLPRC PRC('access') PARM((&SomeFile) +
(&F_OK *ByVal)) +
RTNVAL(&RtnVar)

if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('Exists' *bcat &SomeFile)
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo

/*===================================== */
/* Check for read/write access */
/*===================================== */

CHGVAR VAR(&Mode) VALUE(&R_OK + &W_OK)
CALLPRC PRC('access') PARM((&SomeFile) +
(&Mode *ByVal)) +
RTNVAL(&RtnVar)
if (&RtnVar *EQ 0) do
SNDPGMMSG MSG('You have read & write access!')
enddo
ELSE DO
CALLPRC PRC('__errno') RTNVAL(&ERRPTR)
CHGVAR VAR(&MSGNO) VALUE(&ERRNO)
CHGVAR VAR(&MSGNOC) VALUE(&ERRNO)
CHGVAR VAR(&MSGID) VALUE(CPE *TCAT &MSGNOC)
SNDPGMMSG MSGID(&MSGID) MSGF(QCPFMSG) MSGTYPE(*DIAG)
SNDPGMMSG MSG('Error, see diagnostic message')
enddo

ENDPGM

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD



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

message: 3
date: Wed, 16 Aug 2017 08:28:26 +0300
from: Gad Miron <gadmiron@xxxxxxxxx>
subject: Secured txt file

Hello pundits

Need advice with the following:

I'm asked to create on the i a "payment instructions" text file to be sent to our bank.
The actual uploading of the file to the bank is done by a special secured *PC based* software.

When testing the process someone pointed to me the need to prevent any user (i user or domain user) from changing the content of this text file.

I can create a txt file on the IFS and deny i users access to it (using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to send it to the bank then the access restrictions on the i are no longer valid.

I guess it is worth mentioning that we do not use SSO (Single sign on) for accessing the i


TIA

Gad


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

message: 4
date: Tue, 15 Aug 2017 23:32:03 -0600
from: Jack Woehr <jwoehr@xxxxxxxxxxxxxxxxxxxxxxxx>
subject: Re: Secured txt file

Encrypt.

On Tue, Aug 15, 2017 at 11:28 PM, Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hello pundits

Need advice with the following:

I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.

When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.

I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.

I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i


TIA

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD




--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021

NON-DISCLOSURE NOTICE: This communication including any and all attachments is for the intended recipient(s) only and may contain confidential and privileged information. If you are not the intended recipient of this communication, any disclosure, copying further distribution or use of this communication is prohibited. If you received this communication in error, please contact the sender and delete/destroy all copies of this communication immediately.


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

message: 5
date: Wed, 16 Aug 2017 09:48:51 +0200
from: Tim Bronski <tim.bronski@xxxxxxxxx>
subject: Re: Secured txt file

Hi Gad,

You don't say whether confidentiality is needed as well as integrity or how the process on the PC will work. That said, a solution to detect changes would be to create a PGP detached signature file and send that with the original file to the PC. The PC process would need to perform a signature check immediately before sending to the bank. This involves no encryption so the contents of the original file aren't modified and no key or password is required on the PC end.

Tim


On 8/16/2017 7:28 AM, Gad Miron wrote:
Hello pundits

Need advice with the following:

I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.

When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.

I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.

I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i


TIA

Gad

--
Need sFTP or PGP? Download your native sFTP or OpenPGP solutions here:
www.arpeggiosoftware.com

---
This email has been checked for viruses by AVG.
http://www.avg.com



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

message: 6
date: Wed, 16 Aug 2017 09:35:24 +0000
from: Jonathan Wilson <piercing_male@xxxxxxxxxxx>
subject: Re: Secured txt file

On Wed, 2017-08-16 at 08:28 +0300, Gad Miron wrote:
Hello pundits

Need advice with the following:

I'm asked to create on the i a "payment instructions" text file to be
sent to our bank.
The actual uploading of the file to the bank is done by a special
secured *PC based* software.

When testing the process someone pointed to me the need to prevent any
user (i user or domain user) from changing the content of this text file.

I can create a txt file on the IFS and deny i users access to it
(using
CHGAUT)
BUT when the file is copied from the IFS to the user's PC in order to
send it to the bank then the access restrictions on the i are no
longer valid.

I guess it is worth mentioning that we do not use SSO (Single sign on)
for accessing the i

Could you just have the requirement that the file should be loaded/transmitted from a mapped drive and/or full url? The application would load the file (which after creation would be made read only on the
i) from (for example) smb:myIserver\securefolder\thisfileisreadonly.txt?
(1)

Obviously that would require the user not to copy the file locally, edit it, and then transmit the local copy... but if there is an application involved which requires user input (via gui or command line foo) then there has to be some level of trust.

Obviously if the raw file contains some kind of checksumming then, theoretically, it would be harder to edit the file and have it pass the pc applications validation but that is down to the pc application.

It sounds very similar to the old bacs processing problem, when it was far cheaper and simpler to have a 386/486 with a dial up modem send the bacs file than having it done by the "400"... I really don't miss the days of creating a pc file transfer script which would be remotely executed by the green screen (I remember it being possible but for the life of me can't remember what it was called or how it worked) and then after working for months something would go wrong and the pc would get re-installed, or replaced, and the batch/transfer definition file would be lost.

(1) If the application remembers the url then it would just be a case of re-using a fixed file name and all the user would have to do is click the big red <send> button... assuming the pc application is clever enough to know if the content of the file has been previously sent and/or the receiving bank application is clever enough to put on hold a batch if it seems as if its a duplicate transmission.



TIA

Gad



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

Subject: Digest Footer

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD

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

End of MIDRANGE-L Digest, Vol 16, Issue 1295
********************************************


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.